Back to MarketAssessment main page

Use-Case Model

Во attachments има стари и несредени датотеки кои не одговараат на напишаното. Треба да се проверат сите, тие што може и треба да се ажурираат, а останатите што не се веќе валидни да се избришат од тука. Доколку некои се посоодветни во некој use-case опис, тогаш треба од тука да се избришат, а таму да се додадат.

Актери

• Организации (Компании, институции и образовни институции)
• Поединци (Професионалци и студенти)

Use-Cases

• Клиент - Најава Регистрација - Систем
  • Use Case дијаграм за најава и регистрација во системот
• MarketAssessmentUC Organizations (companies, institutions & educational institutions)
• MarketAssessmentUC Persons (Professionals & Students)

клиент стои недокументирано? што е тоа, дали е уште потребно.

• Use Case дијаграм за функционалностите (Регистрација, Најава, Барање услуга, Нудење услуга, Пребарување информации) на системот при користење од организациите

Кој е овој дијаграм? најдобро тука да биде линкувана конкретната датотека да се знае која е. Ако е нешто за во другите страници, тогаш таму да се пресели а од тука да се избрише.

Податочен модел врз основа на случаи на користење на системот

Главни ентитети, Атрибути

Подвлечете ги кандидат клучевите

Организации:

• Id_организација
• Име на организација
• Вид на организација (Компанија / Институција / Образовна институција - факултет/едикативен центар)
• Единствен број
• Број на вработени (опционално)
• Контакт (е-маил адреса, телефонски број, физичка адреса)
• База која се користи во организацијата

Поединци:

• Id_поединец
• Име и презиме
• Студент или искусен професионалец
• Контакт
• Професија
• Образование
• Дали во Вашата фирма се прават обуки и презентации на новитети на вработените?
• Дали сте заинтересирани за обуки и презентации на новитети?

Регистрација:

• Id_регистрација
• Корисничко име (емаил)
• Лозинка
• Дата
• Тип ( организација/поединец )
  • За Организација : Име
  • За Поединец: Име и презиме

Најава:

• Id_најава
• Корисничко име (емаил)
• Лозинка
• ПоследнаДата

Корисници ентитетот е заменет со најава. Од поединци и организации корисничко име и лозинка се тргнати бидејки ги има во најава и регистрација меѓу кои ке има врска и од таму ке се влечат тие податоци.

Самата идејата е проблематична, бидејќи идејата ги поистоветува концептите Корисник и Најава. Но, знаеме од пракса дека Корисникот и неговата Најава на систем не се исто нешто, бидејќи секој Корисник може реално да има повеќе Најави на системот низ својата историја, па со вакво решение фактички во еден „удар“ го губиме и концептот на Корисник и концептот на Најава, а го губиме и историјатот на Најавите бидејќи се чува само последната. Тоа се проблемите, па треба да се дискутира.

Услуги:

• Име на услуга
• Тип на услуга (Обука за база на податоци/Одржување на база на податоци/Сопствен софтвер/Консултантски услуги/Пракса/Работа/Обука)
• Име на база на податоци
• Тип на база на податоци
• Верзија на менаџмент систем
• Цена на услуга
• Опис на услуга
• Контакт (FK од организацијата од која евнесена ускугата)
• Дата

FK како поим воопшто не постои во модел на ентитети и релации.

Во Услуги е додаден атрибут Дата * за да се опфатат сите времиња сегашно/минато.

Еден ентитет е една услуга, па ќе има само една дата - последната.

За пракса не направивме посебен ентитет бидејки е прикажан како тип на услуга.
Додадени се и Обука и Работа како типови во услуга ( бидејки пракса веќе беше ставено како тип а обука и работа би требало да одат во иста група со пракса, така да или сите одат како тип на услуга или за сите би требало нов ентитен? мислиме дека доколку се чуваат истите информации за сите три типа тогаш е ок вака само што ке бидат тргнати како посебни врски и ке остане само врската x бара/нуди услуга )

Треба да се дискутира попрецизно за сите различни UC - кој на кого ја нуди како услуга праксата, па дали воопшто може да се решат на еден начин сите ситуации.

Врски:

• Поединец се регистрира
• Поединец се најавува
• Поединец бара услуга
• Поединец нуди услуга
• Поединец ажурира податоци
• Поединец пребарува информации
• Организација се регистрира
• Организација се најавува
• Организација бара услуга
• Организација нуди услуга
• Организација ажурира податоци
• Организација пребарува информации

Врските се променети како резултат на тоа што пракса/работа/обука се тип на услуга.

Во сите колекции е додадено Id.

1.Идеја што би требало да бидат податок и инфомација? не личат на ентитети
2.Идеја што со оваа забелешка " Треба да размислувате поформално, како бара услуга некоја организација? Дали објавува оглас, пушта јавно соопштение, праќа мејл до некого? Тие работи треба да се евидентираат" ( мислиме дека ако го додадиме ова многу ќе се искомплицираат работите.
Би сакале најпрво да финализираме со ентитети, атрибути и врски па потоа да го направиме ER дијаграмот за да немаме промени и во него.

Повеќе од пола од врските ви се недефинирани. Поврзуваат постоечки со непостоечки работи. Пример: „Поединец се регистрира“, постои множество ентитети Поединци, ама не постои множество ентитети “Регистрации“ за да имате меѓу нив врска „се“. Пример: „Организација нуди услуга“, а не постои множество ентитети „Услуги“. Ова треба да се запрашате за буквално сите врски, бидејќи самата недефинираност на дел од врските укажува дека можеби не сте ги наведувале доволно прецизно и останатите, па можеби и тие не се баш коректни.

За сите врски кои изгледаат како коректни по горната проверка треба да се запрашате дали се баш такви какви што сте ги навеле, односно дали тоа што го поврзуваат е доволно или е потребна покомлексна структура да се репрезентираат. На пример велите “Организација бара услуга“, но со самото тоа што кажувате „бара“ во сегашно време, е исто како да велите “Организацијата Х сега бара услуга за К“. Но, што правиме кога некоја организација барала услуги и во минатото, а тој податок ни е потребен за да може да се прават различните анализи. Наведената врска, не е доволна да репрезентира и сегашна и мината состојба, бидејќи една врска вклучува само еден пар од една Организација и една Услуга - не може да вклучи повеќекратно учество - со други зборови не може да покрие “Организацијата Х сега бара услуга за К1“ и “Организацијата Х лани барала услуга за К2“ и “Организацијата Х преклани барала услуга за К2“ и “Организацијата Х пред 3 години во април барала услуга за К3“. Треба да размислувате поформално, како бара услуга некоја организација? Дали објавува оглас, пушта јавно соопштение, праќа мејл до некого? Тие работи треба да се евидентираат - што повлекува дека само за оваа ситуација ви фалат некои ентитети, прашањето кои и со кои врски тие ќе бидат поврзани со организација и услуга. Вакво размислување треба да спроведете за сите врски за кои потенцијално треба да се чува историјат.