UML-диаграмма классов

Диаграмма классов UML позволяет обозначать отношения между классами и их экземплярами. Отношения между классами любого объектно-ориентированного приложения можно представить в виде такой структурной схемы (Рисунок 1):

Рисунок 1

 

 

Необходимо построить UML-диаграмму классов, а затем отразить ее в объектно-ориентированном коде.

Отношение обобщение – это наследование. Наследование объектом членов другого класса представлено в явном виде в классе Storage_Coursework.UserControls.Material. Это пользовательский элемент управления, унаследовавший свойства и методы класса System.Windows.Forms.UserControl, позволяющий «визуализировать» объект класса Storage_Coursework.Objects.Material. Но наследование происходит в неявном виде. Объект Storage_Coursework.Objects.Material m передается в конструктор пользовательского элемента управления и становится одним из его членов. При построении элемента управления в методе SetupControls() происходит присвоение значений свойствам визуальных элементов от свойств этого члена. В коде метода SetupControls() это выглядит так:

lbMaterialName.Text = material.MaterialName;

т.е. визуальный объект lbMaterialName получает новое значение свойства Text от родительского (хотя наследование не явное) класса material (свойство MaterialName).

Наследование можно представить в виде схемы (Рисунок 2):

Рисунок 2

Отношение ассоциация показывает отношения между объектами-экземплярами класса. Пример бинарной ассоциации можно рассмотреть в отношении классов User и Role пространства имен Storage_Coursework.Objects

Предоставление доступа к приложению осуществляется на основании совокупности прав, закреплённых за ролью. Каждый пользователь имеет только одну роль в приложении, а значит, имеет набор прав доступа, определённых этой ролью. Таким образом между классами User и Role можно установить связь «один к одному» (Рисунок 3).

Рисунок 3

В свойстве User.UserRole получаем единственную роль пользователя так (Листинг 1):

public Role UserRole { get { return Storage_Coursework.Providers. RoleProvider.GetUserRole(this.UserID); } }

Листинг 1

Каждая роль содержит набор разрешений. Соответственно, связь между классами Role и RoleAccess будет «Один ко многим». Такое отношение называется N-арной ассоциацией (Рисунок 4).

Рисунок 4

 

Класс RoleAccess отвечает за права (разрешения), закреплённые за ролями. Например, ролям «администратор», «работник склада» и «прораб» дано разрешение на просмотр списка строительных материалов на складе. Кодовое название (AccessCode) этого разрешения StorageView. Проверку возможности просмотра списка материалов можно реализовать методом (Листинг 2):

public bool ExistAccess(string accessCode) { return Storage_Coursework.Providers.RoleProvider. ExistAccess(this.RoleID, accessCode); }

Листинг 2

 

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

bool access = currentUser.UserRole.ExistAccess(“ShowAdminPanel”)

 

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

 

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

Рисунок 5

 

Отношения 1, 4 – бинарная ассоциация;

Отношение 2 – N-арная ассоциация;

Отношение 3 – обобщение.

 

Классы, описывающие пользователя и права доступа, и классы, описывающие материалы и склад не взаимосвязаны.