Файл: Применение объектно-ориентированного подхода при проектировании информационной системы (Разработка модели процесса AS-IS).pdf

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

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

Глава 2. Применение объектно-ориентированного подхода при проектировании информационной системы

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

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

2.1. Разработка модели процесса TO-BE

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

С использованием информационной системы процесс будет выполняться следующим образом:

---

1. Предварительно система наполняется информацией о соответствиях частей (пунктов) регулирующих документов процессам и подпроцессам, которые они регулируют. База данных, которая является частью этой системы, заполняется данными о сотрудниках организации.
2. Когда у сотрудника возникает необходимость решить определенную задачу (например, отчисление студента с места, субсидируемого из государственного бюджета), он через соответствующий кейс выбирает эту задачу в системе и получает список ссылок на все пункты всех регулирующих документов, которые относятся к выбранной задаче.
3. Сотрудник работает с документами, найденными по ссылкам на предыдущем шаге. При обнаружении неоднозначной трактовки или противоречия между пунктами регламентов, он открывает обсуждение этой проблемы на форуме информационной системы.
4. При инициации обсуждения сотрудник приглашает в обсуждение всех лиц, которых он считает нужным привлечь. При этом он может назначить одного или нескольких модераторов обсуждения, которые будут иметь техническую возможность помечать сообщения участников, написанные на форуме в процессе обсуждения проблемы, как потенциальные либо финальные ее решения.
5. Система отправляет уведомления на электронные адреса всех выбранных на предыдущем шаге лиц, а также ставит к ссылке на пункт регламента отметку о наличии активного обсуждения.
6. Приглашенные в обсуждение участники, после получения уведомления открыв в системе созданное обсуждение, оставляют комментарии относительно проблемы и предлагают решения. Они также могут проголосовать за или против предложенного решения, добавив либо отняв балл от числового рейтинга решения. Они также могут добавить людей в обсуждение.
7. Модератор обсуждения в определенный момент принимает финальное решение по обсуждаемому вопросу, это решение заносится в систему. Модератор также имеет право сменить решение в дальнейшем.
8. В ссылке на данный пункт регламента появляется отметка о наличии решенного вопроса по данному пункту.

2.2. Формулировка требований к информационной системе

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

---

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

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

Функциональные требования. Система должна:

1. Хранить список задач сотрудников организации, регулируемых имеющимся набором регламентов.
2. Хранить ссылки на регулирующие документы, их разделы, пункты, приложения, пункты приложений.
3. Хранить информацию о соответствиях ссылок пункта 2 задачам пункта 1.
4. Хранить информацию о сотрудниках организации, включая ФИО, должность и адрес электронной почты.
5. Позволять пользователем проходить авторизацию и работать с системой от своего имени.
6. Позволять добавлять новых сотрудников, ссылки на новые документы, новые задачи.
7. Допускать привязку одного пункта регламента к нескольким задачам, допускать привязку к одной задаче нескольких пунктов регламентов.
8. Предоставлять площадку для диалога сотрудникам организации – позволять им создавать новые обсуждения с привязкой к определенным документов.
9. Позволять инициатору обсуждения на этапе его создания выбирать, какие лица будут в него приглашены.
10. Позволять инициатору обсуждения на этапе его создания выбирать модераторов обсуждения.
11. Позволять членам обсуждения добавлять к обсуждению новых лиц.
12. Позволять модератору обсуждения принимать решение относительно обсуждаемого пункта документа; сохранять принятое решение с привязкой к обсуждаемому пункту документа.
13. Отображать наличие у пунктов документов обсуждений, а также отмечать обсуждения, в ходе которых модератором было принято решение по результатам обсуждения; позволять просматривать это решение.
14. Уведомлять участников обсуждения о добавлении их к обсуждению, о новых комментариях в обсуждении, о принятом модератором решении.
15. Давать пользователям возможность писать комментарии не только к теме обсуждения, но и к комментариям других пользователей к этой теме.

Нефункциональные требования. Система должна:

1. Состоять из базы данных и web-интерфейса.
2. Иметь удобный графический пользовательский интерфейс.
3. Быть расширяемой и возможной к применению не только в СПТ, но и в других организациях, осуществляющих работу с регламентами.
4. Организовывать общение в обсуждениях в формате форума.

---

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

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

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

2.2. Проектирование базы данных

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

Существуют различные подходы к проектированию баз данных. Двумя основными являются восходящий и нисходящий.

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

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

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

---

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

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

Таблица 2.1. Сравнительный анализ моделей данных

	Преимущества	Недостатки
Реляционная модель	1. Простота и понятность структуры модели данных для пользователя, т.к. основная конструкция для организации данных – таблица. 2. Независимость данных. В случае необходимости изменения или дополнения структуры модели данных в прикладных программах требуется внести минимальные изменения. 3. Строгие правила проектирования, основанные на математическом аппарате и теории нормализации. 4. Используется большинством современных СУБД.	1. Относительно низкая скорость доступа к данным. 2. Большой расход памяти для представления данных. 3. Множество таблиц в сложных БД приводит к трудности восприятия модели. 4. Предметная область не всегда может быть представлена в виде таблиц.
Иерархическая модель	1. Минимальный расход памяти. 2. Принцип подчиненности сущностей друг другу является естественным для многих предметных областей.	1. Сложность понимания модели для пользователя. 2. Относительно медленный доступ к данным нижних уровней иерархии. 3. Неуниверсальность. Связи между сущностями многих предметных областей сложно или невозможно представить в виде набора иерархических отношений. 4. Для предметных областей с нетривиальными логическими связями модель становится громоздкой. 5. Не используется современными СУБД.
Сетевая модель	1. Универсальность. Модель позволяет выразить больше типов связей между сущностями предметной области. 2. Гибкость. Модель позволяет описать предметную область, которую невозможно представить в виде иерархии. 3. Быстродействие. 4. Стандартизация. Стандарт CODASYL определяет базовые понятия модели и формальный язык описания.	1. Жесткость. Изменение структуры базы данных ведет к необходимости перестроения всей базы данных. 2. Сложность структуры хранения базы в памяти. 3. Относительно слабая поддержка моделей такого типа современными СУБД.

---