Analýza a návrh pro Systém Správce

Toto je analýza aplikace Systém Správce, která slouží k alokaci zaměstnanců vedených v databázi do týmů. Jedná se o pomůcku projektových manažerů.

Rozbor požadavků

Funkční požadavky

1. Přístup Popis: Uživatel aplikace se může do systému přihlásit pomocí platného uživatelského jména a

hesla.

Priorita: must have Akceptační kritérium: Libovolný registrovaný uživatel se může přihlásit do aplikace. 2. Změna hesla Popis: Uživatel si může změnit heslo. Priorita: must have Akceptační kritérium: Přihlášený uživatel si může změnit svoje heslo.

Požadavky podle rolí

Role určuje, jakou funkčnost bude mít daný uživatel k dispozici.

Admin

1. Správa systému Popis: Systém vždy obsahuje správcovský účet "admin". Priorita: must have Akceptační kritérium: Do čisté instalace aplikace se dá přihlásit pod ID "666" a heslem "admin".

2. Založení uživatelského účtu. Popis: Admin může vytvořit nového registrovaného uživatele v některé z rolí zaměstnanec,

personalista nebo projektový manažer.

Priorita: must have Akceptační kritérium: Admin může vytvořit řádově desítky registrovaných uživatelů v

rolích projektový manažer a personalista a řádově stovky uživatelů v roli zaměstnanec.

3. Změna hesla registrovaného uživatele Popis: Admin může změnit libovolnému uživateli heslo. Priorita: must have Akceptační kritérium: Admin může změnit heslo libovolnému registrovanému uživateli v

systému.

4. Smazání existujícího uživatelského účtu Popis: Admin může smazat libovolného uživatele. Priorita: must have Akceptační kritérium: Admin může smazat libovolný účet v systému, kromě sebe.

Projektový manažer

Projektový manažer může spravovat týmy a přidávat do nich zaměstnance. 1. Přidání týmu Popis: Projektový manažer může vytvořit tým a určit jeho jméno a popis. Automaticky se stane

jeho vedoucím.

Priorita: must have Akceptační kritérium: Po přihlášení v roli projektového manažera je možné založit nový

tým a určit u něj jméno a popis. Položka vedoucí týmu je asociována se zakládajícím uživatelem.

2. Editace týmu Popis: Projektový manažer může změnit název, popis a vedoucího týmu, který sám vede. Priorita: should have Akceptační kritérium: Po změně libovolné vlastnosti se tato projeví ve zbytku systému.

Pokud projektový manažer změní vedoucího týmu, tak mu tým zmizí z výpisu vlastních týmů a taky ho nebude moci dále upravovat.

3. Smazání týmu Popis: Projektový manažer může smazat svůj tým. Priorita: should have Akceptační kritérium: Tým po smazání zmizí z databáze spolu s veškerými asociovanými

údaji.

4. Prohledávání databáze profilů Popis: Projektový manažer může prohledávat databázi podle všech položek profilu. Priorita: should have

Akceptační kritérium: Manažer zadá kritéria vyhledávání a zpět dostane seznam vyhovujících profilů.

5. Přidání člena týmu Popis: Projektový manažer může z výpisu vyhledaných profilů přidat člena do týmu. Priorita: should have Akceptační kritérium: U každého profilu ve výsledku vyhledávání je zobrazeno

tlačíko "Add to team". Po jeho stisknutí se vybraný profil přidá do týmu jako člen.

6. Pozvánka Popis: Projektový manažer může rozeslat pozvánku všem členům týmu. Priorita: should have Akceptační kritérium: Po sestavení týmu může projektový manažer zaslat všem

nepotvrzeným členům týmu pozvánku na emailovou adresu uvedenou v profilu.

Zaměstnanec

1. Správa profilu Popis: Zaměstnanec může upravovat informace ve svém profilu. Priorita: must have Akceptační kritérium: Po přihlášení do aplikace v roli zaměstnance je možné upravovat

položky asociovaného profilu a změny uložit nebo zrušit.

2. Potvrzení pozvánky Popis: Zaměstnanec může potvrdit nebo zamítnout pozvánku do týmu. Priorita: should have Akceptační kritérium: V pozvánce jsou obsaženy dva odkazy. Jeden zajišťuje potvrzení

a druhý zamítnutí členství v týmu.

Personalista

Personalista schvaluje informace, které o sobě zaměstnanci uvedli. 1. Schválení profilu Popis: Personalista může schválit jednotlivé položky profilu. Priorita: nice to have Akceptační kritérium: V profilu má personalista možnost schválit jednotlivé položky.

Nefunkční požadavky

1. Desktopová aplikace Uživatelé budou k systému přistupovat pomocí desktopové aplikace, která umožní přihlášení do systému a správu tohoto přihlášení a dále vykonávání všech činností dostupných danému typu účtu. 2. Databáze Systém využívá databázi k ukládání dat. 3. Víceuživatelský systém Se systémem může pracovat naráz víc uživatelů nezávisle na sobě. 4. Výkon Systém zajišťuje správu 500-1000 uživatelů. 5. Bezpečnost dat Informace vedené v aplikaci jsou dostupné jen po přihlášení.

Příklady užití

Analytický model tříd

Popis tříd

Klientská aplikace

EmployeeFrame

Třída vykresluje GUI pro editaci jednotlivých profilů.

LoginFrame

Přihlašovací obrazovka. Zajišťuje připojení k serveru a ověření uživatele.

MainFrame

Hlavní okno aplikace, které se otevře po přihlášení. Obsahuje menu s funkcemi společnými pro

všechny role. Dále obsahuje menu s funkcemi specifickými pro danou roli. Obsahem okna jsou

informace o profilu uživatele.

ChangePassDialog

Tato třída zobrazuje dialog sloužící ke změně hesla uživatele.

Role

Rozhraní s funkcemi charakterizujícími uživatelskou roli.

AdminRole

Třída implementující rozhraní Role. Zajišťuje funkčnost související se správou uživatelů.

Main

Spouštěcí třída, která vytvoří prvotní GUI pro přihlášení.

ServerConnectionInterface

Rozhraní pro třídu komunikující se serverem.

ServerConnection

Třída implementovaná ze ServerConnectionInterface, fungující jako singleton, sloužící ke komunikaci

se serverovou aplikací.

Item

Třída představující položku dovedností zaměstnance.

FrameGroups

Implementace GUI pro správu skupin uživatelů.

FrameItems

Implementace GUI pro správu globálních položek dovedností.

FrameEditGroup

Implementace GUI pro editaci a přiřazování položek dovedností skupiny.

Source

Třída, která si nechá poslat veškeré informace o uživateli ze serverové aplikace a umožňuje s těmito

informaci dále pracovat jiným třídám.

User

Třída představující uživatele. Uchovává si všechna data o uživateli.

Team

Třída představující tým. Uchovává si všechna data o týmu.

FramePMShowTeams

Implementace GUI pro zobrazování týmů projektovému manažerovi.

FramePMEditTeam

Implementace GUI pro vytváření a editaci týmu.

PMRole

Třída implementující rozhraní Role. Zajišťuje funkčnost související se správou týmů.

ViewProfile

Prostá třída sloužící k vykreslení jedné ze základních obrazovek našeho systému - okno s osobními

údaji.

SourceUserInt, SourceGroupInt, SourceTeamInt, SourceItemInt

Rozhraní pro třídy oddělující kódování a dekódování komunikace se serverem od objektových dat.

Každé rozhraní má navržené metody pro kontrolu chyb na straně serveru, jedná se o metody

umožňující přidávání, odebírání, update a získávání jednotlivých elementů.

SourceUser, SourceGroup, SourceTeam, SourceItem

Jedná se o implementaci předchozích rozhraní.

TeamStatus, ItemsStatus

Třída představující elementy a jejich vztahy k ostatním elementům.

Serverová aplikace

ClientConnection

Třída spouštějící se jako samotné vlákno, přes kterou se komunikuje s jednotlivými klienty. Vzniká a

zaniká při připojení a odhlášení uživatele.

Main

Třída poslouchající na portu připojení klientů a přidávající jim komunikační třídu.

Protocol

Třída na základě příchozího požadavku od klienta získá instanci třídy Worker, na které volá metody

pro zpracování požadavku.

Worker

Jedná se o třídu navrženou podle návrhového vzoru Factory. Vytváří objekty, které zpracovávají

všechny možné požadavky od klienta.

DBCInt

Rozhraní pro třídu komunikující s databází.

DBConnection

Třída komunikující s databází. Obsahuje metody vracející Stringy, které jsou posílány klientovi.

UserData

Slouží k vytvoření Hashmapy ve třídě Protocol.

Popis protokolu

Textový protokol komunikace mezi klientem a serverem. Symbol "větší než" značí komunikaci od klienta k serveru. Symbol "menší než" představuje odpověď serveru. Server na požadavek zpravidla odpoví zprávou OK, pokud požadavek vyřídil v pořádku, nebo KO spolu s vysvětlujícím textem. role: Neověřený uživatel > LOGIN use pass < ADMIN | MANAGER | EMPLOYEE | HR | KO duvod Heslo hashované (nice to have). Odpovědí serveru je role uživatele a nebo KO, pokud došlo k chybě přihlášení. role: Přihlášený uživatel > CHANGE_PASS user_id old_pass new_pass < OK | KO důvod role: admin přídání uživatele: > ADD_USER role group pass < user_id | KO důvod smazání uživatele: > DEL_USER user_id < OK | KO důvod změna hesla uživatele: > ADMIN_CHANGE_PASS user new_pass < OK | KO důvod update uživatele: > UPDATE_USER user_id name lastname address city email phone professia < OK | KO důvod žádost o přijetí informací uživatele: > GET_INFO idUser < idRole;idGroup;name;lastname;address;city;email;phone;professia | KO důvod (jedná se pouze o atributy usera,tzn. bez teams a items)

získat všechny id uživatelů v User tabulce: > GET_USERS > id_user1;... | KO důvod (bez mezer za středníkem) získat skupiny dostupné v systému: > GET_GROUPS > id_group1 name1 pocet_items1 item1_id item2_id;id_group2 name2 pocet_items2 item1_id item2_id ...| KO důvod (bez mezer za středníkem) získat všechny položky dovedností ve spojovací tabulce: > GET_ITEMS > id_item1 name1;... | KO důvod (bez mezer za středníkem) získat všechny týmy v databázi: > GET_TEAMS > id pm name goal project info active;.... | KO důvod (bez mezer za středníkem) přidání položky dovednosti: > ADD_ITEM nazev < OK | KO důvod odebrání položky dovednosti: > DEL_ITEM nazev < OK | KO důvod úprava položky dovednosti: > UPDATE_ITEM id_item nazev < OK | KO důvod přidání týmu: > ADD_TEAM pm nazev project info goal < OK | KO důvod úprava týmu: > UPDATE_TEAM id_team nazev project info goal < OK | KO důvod

smazání týmu: > DEL_TEAM id < OK | KO důvod smazání týmu: > DEL_GROUP id_group < OK | KO důvod přidání group: > ADD_GROUP name pocet_items id_items1 id_items2 ... < OK | KO důvod úprava group: > UPDATE_GROUP id_group name pocet_items id_items1 id_items2 ... < OK | KO důvod úprava položky dovednosti: > EDIT_ITEM id_item nazev < OK | KO důvod získat id položek dovedností pro určitého uživatele: > GET_USER_ITEMS id_user > id_item state;.... | KO důvod získat id týmů pro určitého uživatele: > GET_USER_TEAMS id_user > id_team confirmed;.... | KO důvod přidání uživatele do týmu: > USER_IN_TEAM id_user id_item < OK | KO důvod odebrání uživatele z týmu: > USER_OUT_TEAM id_user id_item < OK | KO důvod změna stavu účasti uživatele v týmu: > SET_TEAM_CONFIRMED id_user id_team confirmed < OK | KO důvod

změna stavu dovednosti uživatele: > SET_ITEM_STATE id_user id_item state < OK | KO důvod získat všechny uživatele v týmu s id: > GET_TEAM_USERS id_team > id_user confirmed;... | KO důvod (bez mezer za středníkem) získat všechny týmy pro PM s id: > GET_PM_TEAMS idPM > id pm name goal project info active;.... | KO důvod (bez mezer za středníkem)

Architektura

Klientská aplikace pomocí grafického rozhraní posílá požadavky serverové aplikaci. Požadavky jsou ve formě textového řetězce v tvaru zaznamenaném v protokolu. Serverová aplikace pomocí protokolu rozpozná požadavek a reaguje připojením k databázi, kde se provede požadovaný SQL dotaz. Následně je klientská aplikace informována o úspěchu či neúspěchu. V případě neúspěchu je konkretizovaný jeho důvod. Výsledek je zobrazen v grafickém prostředí.

Návrh databáze

Návrh uživatelského rozhraní

Následují náčrty uživatelského rozhraní. Jedná se o úvodní studie, skutečné rozhraní aplikace se může lišit.

Přihlášení Návrh přihlašovací obrazovky.

Správa uživatelů dostupná v roli admin.

Návrh pro správu skupin zaměstnanců a jejich dovedností

Správa týmů a přidání týmu v roli projektového manažera