Об'єктно-орієнтована програмна система для управління проектами

Автор работы: Пользователь скрыл имя, 18 Мая 2013 в 14:38, курсовая работа

Описание

Потрібно сказати, що в житті будь-якої компанії буває момент, коли кількість справ, яке змушені контролювати співробітники і особливо керівництво стає таким що перевершують можливості людської пам'яті.
При вирішенні складних завдань буває момент, коли співробітники і керуючі не можуть бачити проект в цілому, втрачається з пам'яті необхідність зробити ті чи інші роботи.
Буває й інша ситуація подібна цій - відділ, що складається більш ніж з 15-20 співробітників працюють одночасно над однією задачею - складна структура для управління, і без спеціальних засобів проконтролювати їх роботу надзвичайно складно. Застарілий метод - нескінченні наради і доповіді - тільки посилює проблему, так як відволікає від ведення головної справи.

Работа состоит из  1 файл

Об'єктно-орієнтована програмна система для управління проектами.doc

— 2.48 Мб (Скачать документ)

При створенні підсистем  в моделі виконуються наступні перетворення:

  • об'єднувані класи поміщаються в спеціальний пакет з ім'ям підсистеми і стереотипом <<subsystem>>;
  • специфікації операцій класів, створюючих підсистему, виносяться в інтерфейс підсистеми — клас із стереотипом <<interface>>;
  • опис інтерфейсу повинен включати:
  • ім'я інтерфейсу, що відображає його роль в системі;
  • текстовий опис інтерфейсу розміром з невеликий абзац, що відображає його обов'язки;
  • опис операцій інтерфейсу (ім'я, що відображає результат операції, алгоритм виконання операції, повертане значення, параметри з їх типами);
  • характер використання операцій інтерфейсу і порядок їх виконання документуються за допомогою діаграм взаємодії, що описують взаємодію класів підсистеми при реалізації операцій інтерфейсу, які разом з діаграмою класів підсистеми об'єднуються в кооперацію з ім'ям інтерфейсу і стереотипом «interface realization»;

        - у підсистемі створюється клас-заступник  із стереотипом <<subsystem ргоху>>, керівник реалізацією операцій  інтерфейсу.

Всі інтерфейси підсистем  повинні бути повністю визначені  в процесі проектування архітектури, оскільки вони служитимуть як точки синхронізації при паралельній розробці системи.

Сторінка авторизації в системі має вигляд:    

Рис. 9. Сторінка авторизації в системі

У вікні авторизації користувач ідентифікує себе за допомогою логіна та пароля, який користувач отримує після проходження реєстрації, сторінка якої має вигляд:

Рис. 10. Сторінка реєстрації в системі

Після авторизації користувач попадає  на головну сторінку:

Рис. 11. Головна сторінка

Щоб створити проект, необхідно перейти  в розділ проекти та натиснути «Новий проект»:

Рис. 12. Сторінка списку проектів

У з’явившийся формі, заповнити  всі поля та натиснути «Створити», або «Створити та продовжити», якщо необхідно перейти до проекту.

Рис. 13. Сторінка з формою створення проекту

 

3.2.2 Проектування елементів системи

Проектування елементів  системи включає:

  • уточнення опису варіантів використання (полягає в модифікації їх діаграм взаємодії і діаграм класів з урахуванням класів, що знов з'явилися на кроці проектування, і підсистем, а також проектних механізмів);
  • проектування класів;
  • проектування баз даних.

Проектування  класів.

Проектування класів включає:

  • деталізацію проектних класів;
  • уточнення операцій і атрибутів;
  • моделювання станів для класів;
  • уточнення зв'язків між класами.

Деталізація проектних класів.

Кожен граничний клас перетвориться в якийсь набір класів залежно від свого призначення. Це може бути набір елементів призначеного для користувача інтерфейсу, залежний від можливостей середовища розробки, або набір класів, що реалізовує системний або апаратний інтерфейс.

Класи-сутності з урахуванням  міркувань продуктивності і захисту  даних можуть розбиватися на ряд  класів. Підставою для розбиття є  наявність в класі атрибутів  з різною частотою використання або  видимістю. Такі атрибути, як правило, виділяються в окремі класи.

Класи, що управляють, реалізовують просту передачу інформації від граничних  класів до суті, можуть бути видалені.

Зберігаються класи, що виконують істотну роботу по управлінню потоками подій (управління транзакціями, розподілена обробка і т.д.).

Одержані в результаті уточнення класи підлягають безпосередній  реалізації в коді системи.

Уточнення операцій і атрибутів.

Обов'язки класів, визначені  в процесі аналізу і документовані  у вигляді операцій "аналізу", перетворяться в операції, які будуть реалізовані в коді. При цьому:

  • кожній операції привласнюється коротке ім'я, що характеризує її результат;
  • визначається повна сигнатура операції (відповідно до нотації, прийнятої в мові UML);
  • створюється короткий опис операції, включаючи сенс всіх її параметрів;
  • задається видимість операції: public, private або protected;
  • визначається область дії операції: екземпляр (операція об'єкту) або класифікатор (операція класу);
  • може бути складений опис алгоритму виконання операції (з використанням діаграм діяльності у вигляді блок-схем, а також діаграм взаємодії різних об'єктів при виконанні операції).

Уточнення атрибутів  класів полягає в наступному:

  • окрім імені атрибуту задаються його тип і значення за умовчанням (необов'язкове);
  • враховуються угоди по іменуванню атрибутів, прийняті у проекті і мові реалізації;
  • задається видимість атрибутів: public, private або protected;
  • при необхідності визначаються похідні (обчислювані) атрибути.

Стрічка меню системи має вигляд:

Рис.14. Стрічка меню системі «Система управління проектами»

Пункт меню Моя сторінка веде до індивідуальної сторінки користувача, де користувач налаштовую сторінку так, щоб вона показувала тільки необхідну інформацію для користувача:

Рис. 15. Індивідуальної сторінки користувача

Пункт меню «Допомога» веде до довідкових матеріалів за допомогою яких користувачу буде легше освоїти систему.

Рис. 16. Сторінка справки

3.2.3 Проектування Бази  Даних

Проектування бази даних  залежить від того, який тип СУБД використовується для зберігання даних - об'єктна або реляційна. Для об'єктних БД ніякого проектування не потрібне, оскільки класи-суті безпосередньо відображаються в БД. Для реляційних БД класи-суті об'єктної моделі повинні бути відображені в таблиці реляційної БД.

Другий етап – визначення логічної структури бази даних. Для реляційної бази даних цей етап є значною мірою формальним, оскільки інформаційно-логічна модель відображається в структуру реляційної бази даних адекватно.

         Структура кожної з таблиць  наведена нижче. 

Таблиця «Проекти»

Таблиця «Проекти-користувачі»

Таблиця «Користувачі»

Таблиця «Ролі»

Наступний етап - конструювання  таблиць бази даних, який здійснюється засобами СУБД. Для реалізації даного програмного продукту було обрано MySQL. Ця система керування базами даних (СКБД) з відкритим кодом була створена як альтернатива комерційним системам. MySQL з самого початку була дуже схожою на mSQL, проте з часом вона все розширювалася і зараз MySQL — одна з найпоширеніших систем керування базами даних. Вона використовується, в першу чергу, для створення динамічних веб-сторінок, оскільки має чудову підтримку з боку різноманітних мов програмування. Створення таблиць в бд буде здійснюватися за допомогою phpMyAdmin — веб-застосунок з відкритим кодом, написаний на мові PHP, представляє собою веб-інтерфейс для адміністрування СКБД MySQL. phpMyAdmin дозволяє через браузер здійснювати адміністрування сервера MySQL, запускати команди SQL та переглядати вміст таблиць й баз даних. Додаток користується великою популярністю у веб-розробників, оскільки дозволяє керувати СКБД MySQL без безпосереднього вводу SQL команд, надаючи дружній інтерфейс.

Рис. 17. Таблиця «Ролі» у phpMyAdmin

Діаграма станів

На діаграмах станів зображають різні стани об’єкта  під час його існування і стимули, які призводять до переходу об’єкта з одного стану у інший.

На діаграмах стану  об’єкти розглядаються як машини станів або скінченні автомати, які  можуть перебувати у одному зі станів скінченного набору станів, і які  можуть змінювати цей стан через  вплив одного зі стимулів зі скінченного набору стимулів. Наприклад, об’єкт типу Сервер мережі може перебувати у одному з таких станів протягом існування:

  • Готовність
  • Очікування
  • Робота
  • Зупинка
  • а подіями, які можуть спричинити зміну стану об’єкта можуть бути
  • Створення об’єкта
  • Об’єкт отримує повідомлення «очікувати»
  • Клієнт надсилає запит на з’єднання мережею
  • Клієнт перериває запит
  • Запит виконано і перервано
  • Об’єкт отримує повідомлення «зупинка»
  • Тощо

Рис. 17. Діаграма станів

РОЗДІЛ 4. ОПИС ПРОГРАМНОГО  ЗАБЕЗПЕЧЕННЯ

4.1 Обмеження на комп’ютерне середовище

Так як система  являє собою web-систему, вона розташовується в інтернеті, тому доступ до системи забезпечується за допомогою браузера. Система має кросбраузерну технологію завдяки якої, система підтримує та виглядає однаково на всіх брузерах.

  Щоб система  правильно функціонувала, на сервері повинно бути встановлено таке програмне забезпечення:

    • Операційна система Ubuntu Server 10.10 x86_64
    • Веб-сервер Apache або nginx;
    • Поштовий сервер Postfix;
    • MySQL з панеллю адміністрування phpmyadmin;
    • Засоби моніторингу: logrotate, Webalizer (або наявний аналог);
    • Засіб захисту від несанкціонованих поштових розсилок (спа</s

Информация о работе Об'єктно-орієнтована програмна система для управління проектами