Введение

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

Существует множество технологий и инструментальных средств, с помощью которых можно реализовать в некотором смысле оптимальный проект ИС, начиная с этапа анализа и заканчивая созданием программного кода системы. Эти технологии представлены 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.2 Унифицированный Язык Моделирования

UML (Unified Modeling Language) - Унифицированный Язык Моделирования. UML – это стандартная нотация визуального моделирования программных систем, принятая консорциумом Object Managing Group (OMG) осенью 1997г., и на сегодняшний день она поддерживается многими объектно-ориентированным CASE продуктами, включая Rational Rose 98i.

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

- компонентную технологию разработки моделей ИС,

- визуальное программирование (RAD средства),

- использование образцов (patterns) при проектировании ИС,

- визуальное представление различных аспектов проекта (визуальное моделирование, CASE - средства)

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

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

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

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

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

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

- повышение качества программного продукта,

- сокращение стоимости проекта,

- поставка системы в запланированные сроки.

Рис. 1. Пример диаграммы классов

При проектировании сложной ИС ее разбивают на части, каждая из которых затем рассматривается отдельно. Возможны два различных способа такого разбиения ИС на подсистемы: структурное (или функциональное) разбиение и объектная (компонентная) декомпозиция. Суть функционального разбиения хорошо отражена в известной формуле: “Программа=Данные + Алгоритмы”. При функциональной декомпозиции программной системы ее структура может быть описана блок-схемами, узлы которых представляют собой “обрабатывающие центры” (функции), а связи между узлами описывают движение данных. Объектное разбиение в последнее время называют компонентным, что нашло отражение в специальном термине: "разработка, основанная на компонентах" (Component Based Development - CBD). При этом используется иной принцип декомпозиции - система разбивается на “активные сущности” – объекты или компоненты, которые взаимодействуют друг с другом, обмениваясь сообщениями и выступая друг к другу в отношении “клиент/сервер”. Сообщения, которые может принимать объект, определены в его интерфейсе. В этом смысле посылка сообщения "объекту-серверу" эквивалентна вызову соответствующего метода объекта.

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

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

Принципы моделирования. Использование языка UML основывается на следующих общих принципах моделирования:

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

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

- иерархическое построение – при описании системы используются различные уровни абстрагирования и детализации в рамках фиксированных представлений. При этом первое представление системы описывает её в наиболее общих чертах и является представлением концептуального уровня, а последующие уровни раскрывают различные аспекты системы с возрастающей степенью детализации вплоть до физического уровня. Модель физического уровня в языке 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)

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

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

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

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

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

Графически состояние действия изображается прямоугольником с закругленными углами (рис. 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 медицинских сестер, большинство из которых имеют высшую или первую квалификационную категорию. Круглосуточно работает дежурная бригада. Основными направлениями работы отделения является лечение пациентов с: острым инфарктом миокарда (в раннем постинфарктном периоде); острым коронарным синдромом (после лечения в отделении реанимации и интенсивной терапии); нарушениями ритма сердца (подбор и коррекция терапии, подготовка к восстановлению ритма сердца); тяжелой (декомпенсированной) сердечной недостаточностью, кардиомиопатиями (дилатационной, гипертрофической), артериальной гипертонией, подготовка и послеоперационное ведение пациентов. Кардиологическое отделение для больных инфарктом миокарда использует все современные методики функциональной диагностики. Жителям города Алексеевки и Алексеевского района, при наличии страхового полиса, медицинская помощь оказывается в рамках ОМС. Жителям других районов РФ на платной основе, либо при наличии направления из федерального агентства по здравоохранению и социальному развитию за счет средств бюджета.

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

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. Структура подсистемы «Диетпитание»

Итак, как можно увидеть, что подсистема «Диетпитание» состоит из трех подразделений: Врач-диетолог; Столовая; Кухня. Функциями этой подсистемы являются следующие: дополнительное обследование пациента (с учетом диагноза, поставленного диагностическим отделением лечебного комплекса); назначение питания пациента, соответствующее его диагнозу и общему состоянию; непосредственно питание пациента – кардиологического больного.

На рисунке 7. можно видеть функциональную схему подсистемы.

Обозначения на схеме рис.7:

информационные потоки;

материальные потоки (блюда).

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

Рис. 7. Циркуляция ресурсов в подсистеме «Диетпитание»

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

Моделируя АИС кардиологического отделения и подсистему «Диетпитания», используем сущности в UML. В UML определены четыре типа сущностей: структурные, поведенческие, группирующие и аннотационные. Сущности являются основными объектно-ориентированными элементами языка, с помощью которых создаются модели.

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

Поведенческие сущности являются динамическими составляющими модели UML. Это глаголы, которые описывают поведение модели во времени и в пространстве. Существует два основных типа поведенческих сущностей:

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

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

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

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

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

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

На рисунке 8 приведено графическое изображение класса «Заказ» в нотации UML.

Рис. 8. Изображение класса в UML

Классы в UML изображаются на диаграммах классов, которые позволяют описать систему в статическом состоянии — определить типы объектов системы и различного рода статические связи между ними.

Классы отображают типы объектов системы. Между классами возможны различные отношения, представленные на рисунке 9: зависимости, которые описывают существующие между классами отношения использования; обобщения, связывающие обобщенные классы со специализированными; ассоциации, отражающие структурные отношения между объектами классов.

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

^{Рис. 9. Отображение связей между классами}

^{Ассоциация — это отношение, показывающее, что объекты одного типа неким образом связаны с объектами другого типа («клиент» может сделать «заказ»). Если между двумя классами определена ассоциация, то можно перемещаться от объектов одного класса к объектам другого. При необходимости направление навигации может задаваться стрелкой. Допускается задание ассоциаций на одном классе. В этом случае оба конца ассоциации относятся к одному и тому же классу. Это означает, что с объектом некоторого класса можно связать другие объекты из того же класса. Ассоциации может быть присвоено имя, описывающее семантику отношений. Каждая ассоциация имеет две роли, которые могут быть отражены на диаграмме на рисунке 10. Роль ассоциации обладает свойством множественности, которое показывает, сколько соответствующих объектов может участвовать в данной связи. Рисунок иллюстрирует модель формирования заказа. Каждый заказ может быть создан единственным клиентом (множественность роли 1.1). Каждый больной может создать один и более заказов (множественность роли 1..n). Направление навигации показывает, что каждый заказ должен быть «привязан» к определенному клиенту – больному кардиологического отделения.}

^{Рис. 10. Свойства ассоциации}

^{На диаграммах прецедентов, кроме связей между действующими лицами и прецедентами, возможно использование еще двух видов связей между прецедентами: «использование» и «расширение» (рис. 11). Связь типа «расширение» применяется, когда один прецедент подобен другому, но несет несколько большую функциональную нагрузку. Ее следует применять при описании изменений в нормальном поведении системы. Связь типа «использование» позволяет выделить некий фрагмент поведения системы и включать его в различные прецеденты без повторного описания. На рисунке 11 показано, что при исполнении прецедента «формирование заказа» возможно использование информации из предыдущего заказа, что позволит не вводить все необходимые данные. А при исполнении прецедентов «оценить риск сделки» и «согласовать цену» необходимо выполнить одно и то же действие — рассчитать стоимость заказа. Динамические аспекты поведения системы отражаются приведенными ниже диаграммами.}

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

^{Прямоугольники на диаграмме представляют различные объекты и роли, которые они имеют в системе, а линии между классами отображают отношения (или ассоциации) между ними. Сообщения обозначаются ярлыками возле стрелок, они могут иметь нумерацию и показывать возвращаемые значения.}

^{Рис. 11. Связи на диаграммах прецедентов}

^{Существуют два вида диаграмм взаимодействия: диаграммы последовательностей и кооперативные диаграммы.}

^{Диаграммы последовательностей. Этот вид диаграмм используется для точного определения логики сценария выполнения прецедента. Диаграммы последовательностей отображают типы объектов, взаимодействующих при исполнении прецедентов, сообщения, которые они посылают друг другу, и любые возвращаемые значения, ассоциированные с этими сообщениями. Прямоугольники на вертикальных линиях показывают «время жизни» объекта. Линии со стрелками и надписями названий методов означают вызов метода у объекта. Сообщения появляются в той последовательности, как они показаны на диаграмме — сверху вниз. Если предусматривается отправка сообщения объектом самому себе (самоделегирование), то стрелка начинается и заканчивается на одной «линии жизни».}

^{На диаграммы может быть добавлена управляющая информация: описание условий, при которых посылается сообщение; признак многократной отправки сообщения (маркер итерации); признак возврата сообщения.}

^{Рис. 12. Диаграмма последовательности обработки заказа}

^{Вводятся строки заказа; по каждой строке проверяется наличие продуктов; если запас достаточен — инициируется поставка на кухню; если запас недостаточен — инициируется дозаказ (повторный заказ).}

^{Рис. 13. Кооперативная диаграмма прохождения заказа}

^{На кооперативных диаграммах объекты (или классы) показываются в виде прямоугольников, а стрелками обозначаются сообщения, которыми они обмениваются в рамках одного варианта использования. Временная последовательность сообщений отражается их нумерацией. Диаграммы состояний используются для описания поведения сложных систем. Они определяют все возможные состояния, в которых может находиться объект, а также процесс смены состояний объекта в результате некоторых событий. Эти диаграммы обычно используются для описания поведения одного объекта в нескольких прецедентах.}

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

^{Переходы имеют метки, которые синтаксически состоят из трех необязательных частей (см. рис.14:}

^{Рис. 14. Диаграмма состояний объекта «заказ»}

^{<Событие> <[Условие]> < / Действие>. На диаграммах также отображаются функции, которые выполняются объектом в определенном состоянии. Синтаксис метки деятельности: выполнить/< деятельность >.}

^{Диаграмма деятельности — это частный случай диаграммы состояний. На диаграмме деятельности представлены переходы потока управления от одной деятельности к другой внутри системы. Этот вид диаграмм обычно используется для описания поведения, включающего в себя множество параллельных процессов.}

^{Основными элементами диаграмм деятельности являются (рис. 15):}

^{Рис. 15. Диаграмма деятельности — обработка заказа, овалы, изображающие действия объекта; линейки синхронизации, указывающие на необходимость завершить или начать несколько действий (модель логического условия «И»); ромбы, отражающие принятие решений по выбору одного из маршрутов выполнения процесса (модель логического условия «ИЛИ»); стрелки — отражают последовательность действий, могут иметь метки условий}

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

^{Любая деятельность может быть подвергнута дальнейшей декомпозиции и представлена в виде отдельной диаграммы деятельности или спецификации (словесного описания).}

Заключение

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

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

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

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

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

С учетом особенностей и предпочтений персонала, а также требований администрации к уровню надежности и защищенности данных создана информационная система кардиологического отделения подсистемы «Диетпитание» ЦРБ. Рассмотрели возможность моделирования АИС кардиологического отделения в системе унифицированного языка 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. Схема информационных и материальных потоков подразделений подсистемы «Диетпитание» с подразделениями других подсистем комплекса

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