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

Автор: Пользователь скрыл имя, 04 Декабря 2011 в 18:32, курсовая работа

Краткое описание

UML (от англ. Unified Modeling Language — унифицированный язык моделирования) – язык графического описания для объектного моделирования в области разработки программного обеспечения. UML является языком широкого профиля, это открытый стандарт, использующий графические обозначения для создания абстрактной модели системы, называемой UML-моделью. UML был создан для определения, визуализации, проектирования и документирования в основном программных систем. UML не является языком программирования, но в средствах выполнения UML-моделей как интерпретируемого кода возможна кодогенерация.
UML может использоваться для визуализации, спецификации, конструирования и документирования результатов программных проектов. UML — это не визуальный язык программирования, но его модели прямо транслируются в текст на языках программирования и даже в таблицы для реляционной БД.
Преимущества UML
UML объектно-ориентирован, в результате чего методы описания результатов анализа и проектирования семантически близки к методам программирования на современных ОО-языках;
UML позволяет описать систему практически со всех возможных точек зрения и разные аспекты поведения системы;
Диаграммы UML сравнительно просты для чтения после достаточно быстрого ознакомления с его синтаксисом;
UML расширяет и позволяет вводить собственные текстовые и графические стереотипы, что способствует его применению не только в сфере программной инженерии;
UML получил широкое распространение и динамично развивается.

Оглавление

АННОТАЦИЯ 2
ВВЕДЕНИЕ 4
1 Разработка концептуальной модели системы 5
1.1 Основные и второстепенные цели создания программного продукта 5
1.2 Состав пользователей 5
1.3 Интересы групп пользователей 5
1.4 Разделы программного продукта 5
1.5 Диаграмма вариантов использования (Use case diagram) 6
2 Разработка логической модели системы 9
2.1 Диаграмма деятельности (Activity diagram) 9
2.2 Диаграмма состояний 12
2.3 Диаграмма последовательностей (Sequence diagram) 14
2.4 Диаграмма классов (Class diagram) 16
2.5 Диаграмма компонент (Component diagram) 17
2.5 Диаграмма компонент (Component diagram) 18
2.6 Диаграмма размещения ( 19
3 Разработка и реализация тестов 22
4 Оценка характеристик разработанной модели системы 26
4.1 Набор метрик Чидамбера и Кемерера 26
Заключение 29
Библиографический список 30

Файлы: 1 файл

Поликлиника.doc

— 277.50 Кб (Скачать)

   Федеральное агентство по образованию Российской Федерации

   Государственное образовательное учреждение высшего  профессионального образования

   «Южно-Уральский  государственный университет»

   Факультет «Экономика и управление»

   Кафедра «Информатика» 
 
 
 
 
 

   Разработка модели системы автоматизации работы поликлиники 
 
 
 

   ПОЯСНИТЕЛЬНАЯ ЗАПИСКА

   К КУРСОВОЙ РАБОТЕ

   по  дисциплине «разработка и стандартизация»

   ЮУрГУ – 080801.07-1927-561 ПЗ КП 
 
 
 

   Нормоконтролер, преподаватель Руководитель, преподаватель

   С.Ю.Нестеренко   С.Ю.Нестеренко

   _________________ 2011 г. _________________ 2011 г. 
 

                   Автор проекта

                   студент группы ЭиУ-525

                    Кураченко Е.С.

                   _________________ 2011 г. 
                 

                   Проект защищен 

                   с оценкой

                   _______________________

                   _________________ 2011 г. 
                 
                 
                 

Челябинск 2011

 

АННОТАЦИЯ

 

              Кураченко Е.С. Разработка модели системы автоматизации  работы поликлиники– Челябинск: ЮУрГУ, ЭиУ-525, 2011, с, рисунков 11, 4 таблицы, библиографический список - 4 наименований.  
               

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

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

 

Оглавление

 

ВВЕДЕНИЕ

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

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

     Преимущества UML

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

 

 
1 Разработка концептуальной модели системы

1.1 Основные и второстепенные цели создания программного продукта

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

Второстепенные цели:

- автоматизация  ввода информации о пациентах;

- автоматизация  форматирования отчетов;

-автоматизация  работы с историей болезни;

1.2 Состав пользователей

Пользователями одной системы являются:

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

- врач осуществляет прием больных, формирует историю болезни;

1.3 Интересы групп пользователей

     Группа  пользователей "Администраторы" заинтересованы в:

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

   Группа  пользователей "Врачи" заинтересованы в:

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

1.4 Разделы программного  продукта

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

  1. Модуль приема пациентов;
  2. Модуль формирования истории болезни;
  3. Модуль учета работы врачей;
  4. Модуль регистрации пациентов;
  5. Модуль выдачи талонов.

1.5 Диаграмма вариантов  использования (Use case diagram)

     Диаграмма прецедентов (англ. use case diagram, диаграмма  вариантов использования) — диаграмма, на которой отражены отношения, существующие между актерами и прецедентами.

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

При работе с вариантами использования важно  помнить несколько простых правил:

  • каждый прецедент относится как минимум к одному действующему лицу;
  • каждый прецедент имеет инициатора;
  • каждый прецедент приводит к соответствующему результату (результату с «бизнес-значением»).

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

 

 

 
 
 
 

 

 

 
 
 
 
 
 

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

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

   Описание  актеров:

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

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

         Описание прецедентов:

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

     Формирование  истории болезней – прецедент позволяет редактировать и вводить новую информацию в карточке пациента.

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

     Регистрация – прецедент позволяет осуществлять ввод новой информации о пациентах.

     Выдача  талонов – данный прецедент необходим для выдачи талонов, при посещении определенного врача.

 

2 Разработка логической модели  системы

    1.   Диаграмма деятельности (Activity diagram)

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

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

   На  рисунке 2 представлена диаграмма деятельности авторизации, а на рисунке 3 – прием пациента. 

 

 
 

 

 

    

 

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

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

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

Информация о работе Разработка модели автоматизации системы обслуживания в поликлинике