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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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



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

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

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

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

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


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

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

---

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

---