Поведенческие сущности являются динамическими составляющими модели 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. Схема информационных и материальных потоков подразделений подсистемы «Диетпитание» с подразделениями других подсистем комплекса
В функции врача-диетолога также входит процесс замены одного продукта на другой, эквивалентный первому по составу, в случае отсутствия или нехватки его на складе. Информация об отсутствии или недостаточном количестве продуктов на складе поступает к врачу-диетологу со склада.
Страницы: 1, 2, 3, 4, 5
