стратором системи. Адміністратор системи - співробітник компанії, відповідальний за функціонування ІС, настройку та забезпечення цілісності даних.
Вимоги до системи в цілому:
· Система повинна надавати повноцінний віконний інтерфейс Windows-програми;
· Система повинна надавати широкі і гнучкі можливості настройки і доопрацювання під потреби підприємства;
· Система повинна забезпечувати безпеку на рівні розмежування прав доступу користувачів за ролями і відповідно з організаційною структурою підприємства;
Функціональні вимоги
Система повинна дозволяти вести загальну інформацію з наступних довідників:
· Користувачі;
· Ролі користувачів;
· Права доступу;
· Будівельні матеріали
А також дозволяти проводити операції з даними таблиці «склад», обробляючи і по можливості виключаючи помилки користувача введення.
Система повинна забезпечувати зберігання архівних даних з проведених операціях з прив'язкою до користувачів, що ініціювали зміну даних.
Система повинна дозволяти отримувати звіти по шаблонах, затвердженим Керуючим компанії.
Проектування системи
Процес проектування програми був розбитий на три етапи: Проектування структури класів додатки, проектування бази даних і проектування інтерфейса.діаграмма класів
Діаграма класів UML дозволяє позначати відносини між класами і їх екземплярами. Відносини між класами будь-якого об'єктно-орієнтованого додатки можна представити у вигляді такої структурної схеми (Малюнок 1):
Малюнок 1
Необхідно побудувати UML-діаграму класів, а потім відобразити її в об'єктно-орієнтованому коді.
Ставлення узагальнення - це спадкування. Спадкування об'єктом членів іншого класу представлено в явному вигляді в класі Storage Coursework. User Controls.Material. Це користувача елемент управління, який успадкував властивості і методи класу System.Windows. Forms. User Control, що дозволяє «візуалізувати» об'єкт класу Storage_Coursework. Objects. Material. Але спадкування відбувається в неявному вигляді. Об'єкт Storage_Coursework. Objects. Material m передається в конструктор користувача елементу управління і стає одним з його членів. При побудові елемента керування в методі Setup Controls () відбувається присвоєння значень властивостям візуальних елементів від властивостей цього члена. У коді методу SetupControls () це виглядає так: .Text=material.MaterialName;
т.е. візуальний об'єкт lbMaterialName отримує нове значення властивості Text від батьківського (хоча успадкування не явне) класу material (властивість MaterialName).
Спадкування можна представити у вигляді схеми (Малюнок 2):
Ставлення асоціація показує відносини між реалізованими об'єктами класу. Приклад бінарної асоціації можна розглянути відносно класів User і Role простору імен Storage_Coursework. Objects
Надання доступу до додатка здійснюється на підставі сукупності прав, закріплених за роллю. Кожен користувач має тільки одну роль в додатку, а значить, має набір прав доступу, певних цією роллю. Таким чином, між класами User і Role можна встановити зв'язок «один до одного» (Малюнок 3).
Малюнок 2
Малюнок 3
У властивості User.UserRole отримуємо єдину роль користувача так (Лістинг 1):
Role UserRole
{
get
{Storage_Coursework.Providers..GetUserRole (this.UserID);
}
Кожна роль містить набір дозволів. Відповідно, зв'язок між класами Role і RoleAccess буде «Один до багатьох». Таке ставлення називається N-арной асоціацією (Малюнок 4).
Малюнок 4
Клас RoleAccess відповідає за права (дозволу), закріплені за ролями. Наприклад, ролям «администратор», «працівник складу» і «прораб» дано дозвіл на перегляд списку будівельних матеріалів на складі. Кодова назва (AccessCode) цього дозволу StorageView. Перевірку можливості перегляду списку матеріалів можна реалізувати методом (Лістинг 2):
bool ExistAccess (string accessCode)
{
return Storage_Coursework.Providers.RoleProvider.
ExistAccess (this.RoleID, accessCode);
}
Таким чином, можна виключити клас Ro...
