Архитектура

Архитектура на стариот систем

• Дефинирање на контекстот на системот

Во овој дел даваме преглед на системот и неговата околина. Главните актери во нашиот систем се Презентер и Администратор(кој е претставник на компанијата која го имплементирала системот). Презентерот и Администраторот користат заеднички интерфејс за најава на системот. По извршената најава, според улогите кои ги имаат секој добива пристап на соодветниот интерфејс.

• Анализа на Архитектурата

Системот PresentOrganizer е наменет за користење во рамките на една организација(intra organization), која ќе има потреба од ваков вид на услуга. Во зависност од големината на организацијата која ќе го користи системот, зависи и бројот на корисници на системот. Затоа овој систем треба да овозможиме да биде скалабилен, односно да овозможиме лесно додавање на потребните нови ресурси. Од наведените причини а,и многу други, најсоодветната архитектура за овој систем би била Клиент-Сервер трослојна архитектура .

Целата функционалност на системот ќе биде сместена на серверот и ќе комуницира со базата на податоци. Клиентите ќе може да го користат системот од сите web- прелистувачи поради тоа што апликацијата не подржува некоја активна web содржината како Flash или слично.

Објектно ориентирана декомпозиција на подсистемите во нашиот проект.

• Анализа на Кориснички случаи

Во овој дел е прикажано однесувањето за секој кориснички случај. За приказ на однесувањето користевме секвенцен дијаграм.

1. Додавање презентер
2. Додавање на презентација
3. Креирање распоред на презентации
4. Промена на пријавена презентација
5. Бришење на презентација

• Operation Analysis

Operation Analysis за секој Use-Case на системот:

System Use-Case <Додавање презентер>
Step	Actor Action	Black-Box Step Description	Black-Box Budget Requirements	System Operation	Subsystem White-Box Step Description
1	АА1: оваа акција почнува кога админ ги пополнува полинњата на формата за додавање	BBS1: По секој внесен податок се валидира влезот. Дали е во согласност со барањата.	/	RequredFiled Validator на страната AdminPocetna.aspx	Во почетен Интерфејс на Администраторот се валидира секој влез и се праќа порака на излез(формата) за дали е точен влезот.
2	АА2: оваа акција почнува кога админ во истата форма додава корисничко име и email за презентерот	BBS2: Системот прави проверка дали се валидни влезовите и дали веќе постои внсеното корисничко име или mail	/	MembershipCreateStatus го креира статусот на корисничкото име и password дали се валидни, дали не е внесено ништо...	Во почетен Интерфејс на Администраторот се валидира секој влез и се праќа порака на излез(формата) за дали е точен влезот.
3	АА3: оваа акција почнува кога админ клика на копчето Додади од формата за додавање.	BBS3: Системот додава нов презентер во табелата Prezenteri во базата DBPrezentacii	/	Системска операција: bProfil_Click(object sender, EventArgs e) го додава корисникот во улога Презентер и со повик на ServiceReferencePrezentacii новиот презентер се внесува во табелата Prezenteri	Во почетен инетрфејс на Администраторот.

System Use-Case <Додавање на презентација>
Step	Actor Action	Black-Box Step Description	Black-Box Budget Requirements	System Operation	Subsystem White-Box Step Description
1	АА1: оваа акција почнува кога презентерот ги пополнува полињата од формата за внесување	BBS1: системот ги валидира внесените податоци	/	MaskedEditValidator Валидатор за tbvreme, за дали времетраењето е внесено во соодветен формат	Во Презентерски почетен интерфејс.
2	АА2: презентерот клика на копчето Пријави	BBS2: Системот додава презентација во табелата Prijaveni од базата DBPrezentacii	/	bprijavi_Click(object sender, EventArgs e) методата ги внесува податоците во табела Prijaveni во базата DBPrezentacii. Пристапува до текстото од сите textbox-ови и ги додава овие податоци во табелата	Во Администраторски поглед за креирање Распоред

System Use-Case <Креирање Распоред на Презентации>
Step	Actor Action	Black-Box Step Description	Black-Box Budget Requirements	System Operation	Subsystem White-Box Step Description
1	АА1: оваа акција почнува кога админ избира од DropDownList датум за кој сака да креира распоред	BBS1: системот ги прикажува сите пријавени презентации на тој датум.	/	Popolni(), метода која го полни GridView-то со сите презентации во тој ден	Во Администраторски поглед за креирање Распоред се валидира секој влез и се праќа порака на излез(формата) за дали е точен влезот.
2	АА2: администраторот клика на копчето Креирај	BBS2: Системот генерира распоред, притоа за секоја презентација го користи времетраењето на презентацијата	Креирањето распоред да не биде подолго од 10 сек.	bkreiraj_Click(object sender, EventArgs e) метода која го креира распоредот и го додава до секоја презентација во labela во Gridview-то	Во Администраторски поглед за креирање Распоред

System Use-Case <Промена на пријавена презентација>
Step	Actor Action	Black-Box Step Description	Black-Box Budget Requirements	System Operation	Subsystem White-Box Step Description
1	АА1: оваа акција почнува кога презентерот клика на копчето Промени	BBS1: Системот отвара нова страна каде ги прикажува старите податоци на презентацијата што сака да ја промени	/	GridView1_RowUpdating(object sender, GridViewUpdateEventArgs e) метода која во сесија ги пренесува податоците на презентацијата која сакеме да ја смениме во друга страна каде што ќе се врши промената.	Во Презентерски интерфејс наменет за Преглед на презентации
2	АА2: Презентерот во формите за промена ги менува потребните податоци	BBS2: Системот ги валидира новите податоци	/	MaskedEditValidator Валидатор за tbvreme, за дали времетраењето е внесено во соодветен формат	Во Презентерски интерфејс за Прoмена на презентација
3	АА3: оваа акција почнува кога презентерот клика на копчето Промени	BBS3: Системот ги запишува промените за презентацијата во табелата Prijaveni	Промените да се зачувуваат за не повеќе од 5 сек.	Системска операција: protected void bpromena_Click(object sender, EventArgs e) ги земува сите промени од textbox-овите на формата и ги запишува во табелата Prijaveni	Во Презентерски интерфејс за Прoмена на презентација.

System Use-Case <Бришење на презентација>
Step	Actor Action	Black-Box Step Description	Black-Box Budget Requirements	System Operation	Subsystem White-Box Step Description
1	АА1: оваа акција почнува кога презентерот клика на копчето Бриши	BBS1: Системот праќа порака на излез за да се потврди акцијата бришење	/	GridView1_RowDataBound(object sender, GridViewRowEventArgs e) метода која праќа порака за потврда на бришењето	Во Презентерски интерфејс наменет за Преглед на презентации
2	АА2: Презентерот клика на копчето за потврда OK	BBS2: Системот ја брише презентацијата од табелата Prijaveni	/	GridView1_RowDeleting(object sender, GridViewDeleteEventArgs e) метода која го изведува бришењето	Во Презентерски интерфејс за Преглед на презентации

Архитектура на новиот систем

• Дефиниција на новите функционалности

1. Администраторот објавува претстоен настан и на почетен интерфејс на корисниците се појавува претстоен настан
2. Администраторот поканува презентери
3. Презентерот одобрува покана
4. Презентерот се пријавува за настанот
5. Администраторот одобрува пријава
6. Самостоен sing up за презентери

• Дефинирање на контекстот на системот

• Анализа на Архитектурата

• Анализа на Кориснички случаи

• Оперативна анализа