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

Аналогично таблице «Документы», должна быть реализована связь типа один-ко-многим с таблицей «ПунктыПриложений» по полю «СсылкаНаПриложение».

1. «ПунктыПриложений». Таблица должна содержать информацию о пунктах приложений. Допускается ситуация, когда приложение не разделено на пункты, например, образец какого-либо заявления или титульного листа. Таблица должна содержать поля:
   • Приложение. Внешний ключ для связи с полем «СсылкаНаПриложение» таблицы «Приложения». Тип TEXT.
   • ПунктПриложения. Внешний ключ для связи с таблицей «ДокументыКОперациям», тип TEXT.
2. «Кейсы». Таблица предназначена для хранения информации о ситуациях, возникающих в ходе работы учебного офиса, регламентированных документами. Таблица должна содержать поле «НазваниеКейса» типа VARCHAR, являющееся ключевым. Должны быть реализованы связи по типу один-ко-многим с таблицей «КейсыИерархия» и «ОперацияКейса» по полю «НазаниеКейса».
3. «КейсыИерархия». Таблица реализует иерархическую структуру списка регламентированных кейсов. Таблица должна содержать поля:
   • КейсВнешний.
   • КейсВнутренний.

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

1. «ОперацииКейса». Таблица должна содержать информацию об операциях, необходимых для решения кейса. Список полей был определен после изучения технологических карт, в настоящее время используемых сотрудниками учебного офиса СПТ Пермь для формализации бизнес-процессов в рамках кейсов. Таблица должна содержать поля:
   • НазваниеОперации. Тип VARCHAR.
   • Кейс. Тип VARCHAR. Оно будет являться внешним ключом для поля «НазваниеКейса» таблицы «Кейсы» в рамках связи типа «один-ко-многим».
   • НомерОперации. В этом поле будет храниться порядковый номер операции в кейсе. При изменении порядка операций в кейсе будет необходимо обновить в базе данных порядковые номера всех операций в кейсе.
   • НазваниеОперации. Тип VARCHAR.
   • Описание Операции. Тип TEXT.
   • СрокиВыполнения. Поле может хранить информацию о сроках выполнения, включающую сложные условия, поэтому имеет смысл присвоить полю тип TEXT.
   • ВнешниеСущности. Описывает внешние по отношению к операции сущности. Тип TEXT.
   • ТребуемыеРесурсы. Тип TEXT.
   • РезультатВыполнения. Тип TEXT.
2. «ДокументыКОперациям». Таблица служит для связи операций, необходимых для решений кейса, регламентирующих их пунктов документов и приложений, а также обсуждений этих пунктов. Таблица должна реализовывать связь типа многие-ко-многим между таблицами «ОперацияКейса», «ПунктыДокументов», «ПунктыПриложений» и «Обсуждения». Таблица должна содержать поля:
   • ПунктДокумента. Это внешний ключ для поля «ПунктДокумента» таблицы «ПунктыДокументов» в рамках связи типа «один-ко-многим». Имеет тип TEXT.
   • ПунктПриложения. Это внешний ключ для поля «ПунктПриложения» таблицы «ПунктыПриложений» в рамках связи типа «один-ко-многим». Имеет тип TEXT.
   • Операция. Это внешний ключ для ключевого поля «idОперации» таблицы «ОперацииКейса» в рамках связи типа «один-ко-многим». Тип unsigned SMALLINT. Если суммарное количество хранимых в БД операций превысит 65 536, тип следует сменить на unsigned MEDIUMINT.
   • Обсуждение. Поле участвует в связи «один-к-одному» с ключевым полем «idОбсуждения» таблицы «Обсуждения» и в связи «один-ко многим» с полем «Обсуждение» таблицы «УчастникиОбсуждений». Такой выбор типов связи объясняется тем, что к каждой паре пункта документа или приложения и операции кейса может быть создано только одно обсуждение, но в этом обсуждении может принимать неограниченное количество участников. Тип поля unsigned SMALLINT.
3. «Обсуждения». Таблица предназначена для хранения информации об обсуждениях на форуме, то есть наборах сообщений по определенному вопросу. Таблица должна содержать поля:
   • idОбсуждения. Тип unsigned SMALLINT. Хранит уникальный идентификатор обсуждения, является ключевым полем таблицы и внешним ключом для связи с таблицами «ДокументыКОперациям», «Сообщения» и «УчастникиОбсуждений».
   • Вопрос. Хранит текст вопроса, или сообщения, которое было введено на этапе инициации обсуждения его создателем. Тип TEXT.
   • Дата. Дата создания обсуждения, тип DATE.
   • Время. Время создания обсуждения, тип TIME.
4. «Сообщения». Таблица предназначена для хранения сообщений в обсуждениях на форуме и должна содержать поля:
   • idСообщения. Уникальный числовой идентификатор сообщения, ключевое поле таблицы, первичный ключ для связи типа «один-ко-многим» с полями «СообщениеВнешнее» и «СообщениеВнутреннее» таблицы «СообщенияИерархия». Тип поля unsigned MEDIUMINT.
   • Обсуждение. Тип unsigned SMALLINT, внешний ключ для связи типа «один-ко-многим» с полем «idОбсуждения» таблицы «Обсуждения».
   • Текст. Поле хранит текст сообщения. Тип TEXT.
   • Статус. Тип VARCHAR, внешний ключ для связи типа «один-ко-многим» с полем «НазваниеСтатуса» таблицы «Статусы». В рамках предметной области предусмотрены два статуса сообщений – «Обычный» и «Решение». Каждое сообщение обязано иметь один из этих статусов, и не более одного сообщения в обсуждении может иметь статус «Решение».
   • Автор. Сотрудник, участвующий в обсуждении, являющийся автором данного комментария. Поле является внешним ключом для связи типа «один-ко-многим» с полем «ЭлектроннаяПочта» таблицы «Сотрудники». Один сотрудник может быть автором нескольких сообщений в одном обсуждении. Тип VARCHAR.
   • Время. Тип TIME, время публикации сообщения.
   • Дата. Типа DATE, дата публикации сообщения.
5. «СообщенияИерархия». Таблица используется для организации иерархии сообщений подобно таблице «КейсыИерархия». Таблица включает два поля:

---

• «СообщениеВнешнее». Является внешним ключом для реализации связи «один-ко-многим» с таблицей «Сообщения». Имеет тип MEDIUMINT. Входит в составной ключ.
• «СообщениеВнутреннее». Является внешним ключом для реализации связи «один-ко-многим» с таблицей «Сообщения». Имеет тип MEDIUMINT. Входит в составной ключ.

1. «Статусы». Таблица должна представлять из себя справочник статусов сообщений. Таблица должна содержать одно поле «НазваниеСтатуса», принимающее в рамках рассматриваемой предметной области одно из значений: «Обычный», «Решение». Также в работе организации могут потребоваться дополнительные статусы для сообщений, в таком случае справочник можно дополнить новыми записями.
2. «УчастникиОбсуждений». Таблица предназначена для хранения информации о том, какие сотрудники участвуют в обсуждениях, а также какие роли в этих обсуждениях имеют сотрудники. Таблица должна содержать поля:
   • Сотрудник. Первичный ключ для связи типа «один-ко-многим» с таблицей «Сотрудники» через ее ключевое поле и внешний ключ «ЭлектроннаяПочта». Тип VARCHAR.
   • Роль. Роль участвующего в обсуждении сотрудника. Поле является внешним ключом для связи типа «один-ко-многим» с таблицей «Роли». Тип «VARCHAR».
   • Обсуждение. Внешний ключ для связи типа «один-ко-многим» с таблицей «Обсуждения». Тип unsigned SMALLINT.

Таблица должна реализовывать связь типа многие-ко-многим между таблицами «Сотрудники», «Роли» и «Обсуждения». Первичным ключом является составной ключ из полей «Обсуждение», «Роль» и «Сотрдуник», так как в рамках предметной области один сотрудник в одном обсуждении может играть только одну роль. Если по каким-то причинам в другой предметной области сотрудник должен будет играть более одной роли, из составного ключа нужно будет исключить поле «Роль».

1. «Роли». Таблица представляет собой справочник возможных ролей участников обсуждения. Таблица должна содержать поле «НазваниеРоли», принимающее одно из значений: «Модератор» или «Участник». В зависимости от специфики бизнес-процессов организации, в которой будет внедряться проектируемая ИС, в таблицу можно добавить записи о дополнительных ролях.
2. «Сотрудники». Таблица должна содержать информацию о сотрудниках учебного офиса. Таблица должна содержать поля:
   • Фамилия. Тип VARCHAR.
   • Имя. Тип VARCHAR.
   • Отчество. Тип VARCHAR.
   • Должность. Тип VARCHAR.
   • ЭлектроннаяПочта. Это поле является ключевым, так как у двух сотрудников не может быть одинаковых корпоративных (или личных) адресов электронной почты. Имеет тип VARCHAR, так как адреса обычно короткие.
   • Пароль. Пароль будет использоваться для входа в систему. Поле имеет тип VARCHAR.

---

Должна быть реализована связь типа «один-ко-многим» с таблицами «Сообщения», «УчастникиОбсуждений» и «ДолжностиСотрдуников» по полю «ЭлектроннаяПочта».

1. «ДолжностиСотрудников». Таблица реализует связь типа «многие-ко-многим» между таблицами «Должности» и «Сотрудники», так как один сотрудник может занимать несколько должностей, и несколько сотрудников организации могут работать на одинаковых должностях. Таблица должна содержать поля:
   • Должность. Поле является внешним ключом для связи с таблицей «Должности» и имеет тип VARCHAR. Является частью составного ключа.
   • Сотрудник. Поле является внешним ключом для связи с таблицей «Сотрудники» и имеет тип VARCHAR. Является частью составного ключа.
2. «Должности». Таблица представляет собой справочник должностей сотрудников. Таблица должна содержать единственное поле «НазваниеДолжности», имеющее тип VARCHAR и являющееся внешним ключом для связей «один-ко-многим» с таблицами «ГруппыДолжностей» и «ДолжностиСотрудников».
3. «Группы» представляет собой справочник групп должностей организации. Под группой понимается набор похожих должностей в разных отделениях организации. Например, в ВШЭ группой должностей может являться группа «Менеджер образовательной программы». Она будет включать менеджеров всех образовательных программ университета. Это упростит процесс приглашения участников в обсуждения, так как можно будет, выбрав группу, моментально выбрать всех ее участников. Таблица должна иметь связь типа один-ко-многим с таблицей «ГруппыДолжностей» по внешнему ключу «НазваниеГруппы». Таблица должна содержать единственное поле «НазваниеГруппы» типа VARCHAR, содержащее в себе название группы должностей.
4. «ГруппыДолжностей». Эта таблица реализует связь «многие-со-многими» между таблицами «Группы» и «Должности», так как в одной группе может содержаться несколько должностей, и каждая должность может числиться в одной из нескольких групп. Например, должность «Менеджер образовательной программы «Бизнес-Информатика» может входить в группы «Менеджеры образовательных программ» и «Бизнес-Информатика». Таблица должна содержать поля:

• «Группа». Это поле является внешним ключом для связи «один-ко-многим» с таблицей «Группы». Имеет тип VARCHAR.
• «Должность». Это поле является внешним ключом для связи «один-ко-многим» с таблицей «Группы». Имеет тип TEXT, так как полное наименование должности может состоять более, чем из 255 символов. Является частью составного ключа.

---

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

Рисунок 2.5. Физическая схема данных

Полученная схема позволяет реализовать хранение всех необходимых для работы информационной системы данных в файле базы данных на базе СУБД MySQL.

2.4. Проектирование прототипа пользовательского интерфейса

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

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

Рисунок 2.6. Экран входа в систему

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

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

Макет страницы выбора кейса показан на рисунке 2.7.

Рисунок 2.7. Экран навигации по кейсам

За основу структуры навигации по кейсам для создания макета интерфейса была взята структура раздела «Студентам» Справочника учебного процесса корпоративного портала СПТ [11]. Это обосновано тем, что, как было выяснено в процессе интервьюирования сотрудников учебного офиса, процессы, рассмотренные в данном разделе, составляют большую часть их работы.

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

---

Фрагмент макета такой страницы показан на рисунке 2.8.

Рисунок 2.8. Вложенные кейсы

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

Рисунок 2.9. Операции кейса

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

Если обсуждения никогда не создавалось, маркер должен выглядеть как светло-серая выносная цитатная рамка со значком «+» внутри: . По наведении она становится черной, по клику ссылает на экран инициации нового обсуждения.

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

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

Макет экрана списка операций с выбранной операцией представлен на рисунке 2.10.

Рисунок 2.10. Операции кейса с выбранной кликом операцией

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

---