Файл: Курсовая работа по дисциплине Проектирование информационных систем на тему.docx

Для разработки модели данной информационной системы потребуются следующие программные инструментарии: BPwin Business Process Design Tool и Microsoft Visio 2010.

2. ПРОЕКТИРОВАНИЕ МОДЕЛИ ИНФОРМАЦИОННОЙ СИСТЕМЫ

2.1. Моделирование бизнес–процессов

Для проанализированной предметной области построим контекстную диаграмму при помощи BPwin Business Process Design Tool.



Рис. 1. Контекстная диаграмма

На диаграмме А–0 представлен в общем виде процесс функционирования детского сада. Показаны основные информационные потоки:

• 
  Входящие потоки:
  

– Воспитанники;

– Работники детского сада;

– Сопроводительные документы.

• 
  Управляющие потоки:
  

– Законодательство.

• 
  Ресурсные потоки:
  

– Информационная система учреждения;

• 
  Выходящие потоки:
  

– Отсчет о комплектовании групп;

– Отчет о нагрузке работников;

– Комплексно-тематический план.
Декомпозируем контекстную диаграмму на три функциональных блока (Рис.2):

• 
  Организовать учет воспитанников;
  
• 
  Организовать кадровый учет, управление персоналом;
  
• 
  Подготовить отчет.
  

Рис. 2. Диаграмма IDEF0

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

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

На этапе «Подготовить отчет» происходит сбор данных и по ним составляется отчет.

Декомпозируем функциональный блок «Организовать учет воспитанников» еще на пять действий (Рис.3):

• 
  Обработка заявок;
  
• 
  Прием воспитанников;
  
• 
  Отказ в приеме;
  
• 
  Регистрация воспитанников в базе;
  
• 
  Определение воспитанников в группы.
  

---

Рис.3. Диаграмма IDEF3 «Организовать учет воспитанников»

Далее декомпозируем функциональный блок «Организовать кадровый учет, управление персоналом» на шесть действий (Рис.4):

• 
  Обработка заявок на работу;
  
• 
  Прием сотрудников на работу;
  
• 
  Отказ в приеме на работу;
  
• 
  Регистрация сотрудников в базе;
  
• 
  Распределение нагрузки;
  
• 
  Установка графика работы.
  

Рис.4. Диаграмма IDEF3 «Организовать кадровый учет, управление персоналом»

Декомпозируем функциональный блок «Подготовить отчет» на три действия (Рис.5):

• 
  Сбор данных;
  
• 
  Составление отчета;
  
• 
  Комплексно-тематический план.
  

Рис.5. Диаграмма DFD «Подготовить отчет»

2.2. Построение UML – диаграмм

Диаграмма вариантов использования

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

Для проектируемой информационной системы диаграмма вариантов использования представлена на рисунке 6.


Рисунок 6 – Диаграмма вариантов использования
На диаграмме вариантов использования представлены 2 роли: родители и заведующий детским садом. Именно они являются элементами внешней среды, взаимодействующими с информационной системой.

Для роли «Родители» доступен вариант использования «Оформление заявления». Роль «Родители» выполняет следующие действия: создает заявление о зачислении, предоставляет данные о ребенке и необходимые документы.

Для роли «Заведующий детским садом» доступен вариант использования «Оформление приказа о зачислении», при котором происходит проверка предоставленных данных и одобрение, либо отказ в зачислении.

---

Диаграмма деятельности

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

Диаграмма деятельности проектируемой информационной системы представлена на рисунке 7.

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

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


Рисунок 7 – Диаграмма деятельности
Построение диаграмм позволяет наглядно представить работу проектируемой системы, обнаружить её слабые стороны и внести изменения перед тем, как приступить к программной реализации.
Диаграмма состояний

Диаграмма состояний – это граф специального вида, вершинами которого являются состояния, а дугами являются переходы из состояния в состояние [10, c. 69]. Главное предназначение данной диаграммы – описать возможные последовательности состояний и переходов, которые в совокупности характеризуют поведение элемента модели в течение его ЖЦ.

Диаграмма состояний для проектируемой информационной системы представлена на рисунке 8.



Рисунок 8 – Диаграмма состояний
На диаграмме отражены состояния приложения и переходы между ними, происходящие под влиянием внешних воздействий. Таким образом, информационная система обладает возможностью нахождения в одном из следующих состояний: «Начальное состояние», «Ожидание ввода логина и пароля», «Проверка пароля», «Авторизация», «Получение бланка», «Ожидание ввода данных», «Обработка данных», «Получение вариантов детских садов», «Выбор желаемого детского сада», «Создание заявки», «Создание приказа о зачислении», «Обновление данных», «Получение приказа о зачислении», «Завершение выполнения заявки», «Конечное состояние».

---

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

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

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

Диаграмма последовательности для проектируемой информационной системы представлена на рисунке 9.


Рисунок 9 – Диаграмма последовательности
На диаграмме последовательности представлены классы и обмен сообщениями между ними на временной оси.

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

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

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

Диаграмма классов для проектируемой информационной системы представлена на рисунке 10.

На диаграмме классов расположены следующие классы:

«Приложение» со стереотипом «Управление;

«Заявка» со стереотипом «Сущность» и следующими атрибутами: «Идентификатор заявки», «Логин», «Пароль», «Введенный пароль», «ФИО», «Дата рождения», «Адрес», «Наличие вакцин». Выполняет операцию «Создать заявку»;

---

Рисунок 10 – Диаграмма классов
«Детские сады» со стереотипом «Сущность» и следующими атрибутами: «Название», «Адрес», «Количество свободных мест», выполняет операции: «Получить информацию о наличии свободных мест» и «Обновить данные»; информационный данный ориентированный приложение

«Принятие решений» со стереотипом «Интерфейс», выполняет следующие операции: «Проверить пароль», «Авторизовать», «Обработать данные» и «Создать приказ о зачислении»;

«Форма ввода данных» со стереотипом «Граница», при помощи которого осуществляются следующие операции: «Ввести логин и пароль», «Заполнить бланк», «Выбрать желаемый детский сад»;

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

3. ЛОГИЧЕСКАЯ И ФИЗИЧЕСКАЯ СТРУКТУРЫ БАЗЫ ДАННЫХ

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

Проанализируем разработанные DFD-диаграммы и построим логическую модель.

На основании разработанных DFD-диаграмм были выявлены следующие сущности («хранилища»):

1. Воспитанники.

2. Работники.

3. Должности.

4. Группы.

5. Занятия.

6. Нагрузка работников.



Рис.11 - Локальная логическая модель «Организовать учет воспитанников»



Рис.12 - Локальная логическая модель «Организовать кадровый учет, управление персоналом»



Рис. 13 - Локальная логическая модель «Подготовить отчет»

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

Все связи включаются в глобальную модель без каких-либо изменений.

---