2.3.3 Физическая модель

Физическая модель базы данных - это реализация модели баз данных в определенной системе управления базами данных. На этапе проектирования СКДИ база данных будет создаваться в среде MS SQL Server, поскольку данный инструмент поддерживает создание реляционных баз данных, отличается надежностью и при использовании в учебных целях является бесплатным.

Физическая схема базы данных изображена на рисунке 2.9.

Рисунок 2.9 Физическая модель данных

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

Глава 3. Разработка модуля

Разработка программного модуля проектирования компетентностной модели будет вестись в среде разработки Visual Studio 2013 на языке C#, так как данные средства использовались при создании прототипов других модулей. Будет разработано настольное WindowsForms приложение.

3.1 Архитектура приложения

В основе разрабатываемого приложения лежит двухуровневая архитектура «клиент-сервер» (рис. 3.1). Двухзвенная архитектура представляет собой модель программного комплекса, предполагающая наличие в нём двух компонентов: клиентского приложения и сервера базы данных, с которым работает приложение.

Рисунок 3.1 Двухзвенная архитектура

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

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

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

Таким образом, имеем следующую логику работы разрабатываемого приложения:

· данные считываются с форм приложения;

· считанные данные передаются в Entity Framework для получения ответа;

· с помощью Entity Framework выполняется запрос к базе данных;

· Entity Framework передает ответ на форму.

Проводя соответствие между звеньями архитектуры и компонентами приложения, получаем, что в данной работе сервером базы данных служит схема базы данных и входящие в нее отношения, клиентом - формы клиентского приложения, а Entity Framework способствует формированию LINQ_запросы для осуществления связи между базой данных и формами приложения (рис. 3.2).

Рисунок 3.2 Приложение

3.2 Разработка интерфейса модуля

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

· поле для выбора бизнес-процесса;

· кнопка для загрузки операций выбранного бизнес-процесса;

· поле для отображения списка операций выбранного бизнес_процесса;

· поле для отображения списка компетенций;

· кнопки для обеспечения возможности редактирования списка компетенций;

· кнопка для перехода на форму установления связи между операциями и компетенциями;

· кнопка для перехода на форму для генерации компетентностной модели исполнителя бизнес_процесса.

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

Рисунок 3.3 Начальный экран

После загрузки бизнес_процесса на левой панели отображается список операций, по нажатию на которую возможно открыть окно для просмотра исполнителя операции (см. рис.3.4). Данная форма содержит кнопки для изменения и добавления ролей, которые выполняют выбранную операцию. Формы для изменения и добавления роли представлены на рисунке 3.5 и рисунке 3.6 соответственно.

Рисунок 3.4 Окно для просмотра роли

Рисунок 3.5 Окно для изменения роли

Рисунок 3.6 Окно для добавления роли

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

· поле для ввода/вывода названия компетенции;

· поле для выбора типа компонента компетенции;

· поле для выбора компонента выбранного типа для добавления в состав компетенции, это же поле служит полем ввода названия компонента для поиска;

· поле вывода состава компетенции;

· кнопка поиска компонента;

· кнопка для перехода к справочнику компонентов;

· кнопка для редактирования состава компетенции;

· кнопка для сохранения внесенных изменений;

· кнопка для отмены сохранения изменений.

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

Рисунок 3.7 Окно для добавления/просмотра компетенции

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

Рисунок 3.8 Окно работы со справочником компонентов компетенции

Форма для работы со справочником компонентов визуально разделена на две части: типы и компоненты. Для каждого объекта реализованы операции добавления, редактирования и удаления, которые осуществляются по нажатию соответствующих кнопок. Окно для добавления типа и компонента аналогичны, пример представлен на рисунке 3.9. Окно для редактирования компонента отличается наличием еще одного поля для выбора типа, так как он тоже может быть изменен (см. рис. 3.10).

Рисунок 3.9 Окно для добавления/редактирования типа

Рисунок 3.10 Окно для редактирования компонента

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

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

· поле для выбора операции бизнес_процесса;

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

· поле для отображения связанных компетенций;

· кнопку поиска компетенции;

· кнопку добавления новой компетенции;

· кнопку для просмотра компетенции;

· кнопку для редактирования списка связанных компетенций;

· кнопку для сохранения установленных связей для данной операции;

· кнопку для генерации матрицы;

· кнопку выхода.

Рисунок 3.11 Форма для установления связи

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

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

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

Рисунок 3.12 Матрица покрытия

Форма для формирования компетентностной модели, изображенная на рисунке 3.13, содержит следующие элементы управления:

· поле выбора исполнителя, который участвует в этом бизнес-процессе;

· кнопку для создания компетентностной модели;

· поле для отображения компетентностной модели;

· кнопку для редактирования компетенции.

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

Рисунок 3.13 Компетентностная модель игрока

3.3 Реализация функций

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

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

Пример реализации функции добавления:

Competence newCompetence = new Competence();

newCompetence.IDCompetence = Guid.NewGuid();

newCompetence.Name = textBox1.Text.Trim();

db.Competence.Add(newCompetence);

db.SaveChanges();

Пример реализации функции обновления:

Competence newCompetence = new Competence();

newCompetence = db.Competence.Find(oldCompetence.IDCompetence);

newCompetence.Name = textBox1.Text;

db.Entry(newCompetence).State = EntityState.Modified;

db.SaveChanges();

Пример реализации функции удаления:

Competence competence = db.Competence.Find(oldCompetence.IDCompetence);

db.Competence.Remove(competence);

db.Entry(competence).State = EntityState.Deleted;

db.SaveChanges();

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

private void CreateMatrix()

{

var result = from bp in db.BusinessProcess

join seq in db.Sequence on bp.IDBusinessProcess equals seq.IDBusinessProcess

join op in db.Operation on seq.IDOperation equals op.IDOperation

join matr in db.Matrix on op.IDOperation equals matr.IDOperation

join com in db.Competence on matr.IDCompetence equals com.IDCompetence

where bp.IDBusinessProcess == oldBP.IDBusinessProcess

select new

{

matrID = matr.IDMatrix,

opName = op.Name.Trim(),

comName = com.Name.Trim(),

};

var groupsC = result.GroupBy(c => c.comName);

var groupsO = result.GroupBy(o => o.opName);

int j = 0;

matrix.Columns.Add("operation", "Операция");

foreach (var gO in groupsO)

{

matrix.Rows.Add();

matrix.Rows[j].Cells[0].Value = gO.Key;

j++;

}

j = 0;

int i = 0;

foreach (var gC in groupsC)

{

matrix.Columns.Add(" ", gC.Key);

i++;

foreach (var op in gC)

{

if (op.comName == matrix.Columns[i].HeaderText)

{

for (int n = 0; n < matrix.Rows.Count; n++)

{

if (op.opName == matrix[0, n].Value.ToString())

j = n;

}

matrix.Rows[j].Cells[i].Value = "X";

}

}

}

}

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

public void CreateModel()

{

treeView1.Nodes.Clear();

var result = (from bp in db.BusinessProcess

join seq in db.Sequence on bp.IDBusinessProcess equals seq.IDBusinessProcess

join op in db.Operation on seq.IDOperation equals op.IDOperation

join r in db.Role on op.IDRole equals r.IDRole

join matr in db.Matrix on op.IDOperation equals matr.IDOperation

join com in db.Competence on matr.IDCompetence equals com.IDCompetence

join con in db.Content on com.IDCompetence equals con.IDCompetence

join el in db.Element on con.IDElement equals el.IDElement

where bp.IDBusinessProcess == newBP.IDBusinessProcess && r.IDRole == role.IDRole

select new CompetenceModel

{

elName = el.Name.Trim(),

comName = com.Name.Trim(),

compID = com.IDCompetence,

eID = el.IDElement

}).Distinct();

var competences = result.ToList().GroupBy(x => x.comName);

int i = 0;

foreach (var compet in competences)

{

treeView1.Nodes.Add(compet.Key);

foreach (var el in compet)

treeView1.Nodes[i].Nodes.Add(el.elName);

treeView1.Nodes[i].Expand();

i++;

}

}

Для проверки матрицы покрытия операций бизнес_процесса компетенциями на полноту была также написана функция CheckAssosiations, которая проверяет наличие связей между операциями выбранного бизнес_процесса с компетенциями. Если хотя бы одна операция бизнес-процесса не связана с компетенцией, то матрица считается неполной и генерация матрицы или компетентностной модели становится невозможной. Исходный код функции представлен ниже:

private bool CheckAssosiations()

{

int k = 0;

List<Operation> ops = (List<Operation>)comboBoxO.DataSource;

List<Guid> matr = db.Matrix.Select(m => m.IDOperation).ToList();

foreach (var op in ops)

if (matr.Contains(op.IDOperation))

k++;

if (k == ops.Count)

return true;

else return false;

}

3.4 Разработка тестового примера

Проведем проектирование компетентностной модели исполнителя бизнес_процесса на основе следующих данных. Предположим, проектировщик создал модель унифицированного бизнес_процесса «Разработка программного обеспечения», состоящего из шести операций (см. рис. 3.14). В таблице 3.1 представлены связи между операциями, исполнителями и компетенциями. Прежде чем генерировать компетентностную модель, необходимо установить связи между операциями и компетенциями (см. рис. 3.15).

Таблица 3.1 Связи операций и компетенций

На основании внесенных в программный модуль данных становится возможна генерация матрицы покрытия операций бизнес_процесса компетенциями. Сформированная для рассматриваемого примера матрица представлена на рисунке 3.16.

Рисунок 3.16 Матрица покрытия для бизнес-процесса «Разработка ПО»

На основе созданной матрицы покрытия сгенерируем компетентностную модель для Старшего программиста. Визуальное представление модели изображено на рисунке 3.17.

Рисунок 3.17 Компетентностная модель Старшего программиста

В данной главе работы приведена архитектура разработанного приложения и разработка интерфейса модуля проектирования компетентностной модели исполнителя бизнес-процесса. На данном этапе реализованы требуемые функции. Разработанный функционал программного модуля продемонстрирован на примере простого бизнес_процесса.

Заключение