Back to MarketAssessment main page

Use-Case Model

Актери

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

Use-Cases

• Клиент - Најава Регистрација - Систем
  • Use Case дијаграм за најава и регистрација во системот

• Организација (Компании, институции и образновни институции):

MarketAssessmentUC Organizations (companies, institutions & educational institutions)

• Поединци (Професионалци и студенти):

MarketAssessmentUC Persons (Professionals & Students)

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

Генерална забелешка: додадени се слики со use-case дијаграми, но истите не се наведени во списоците, ниту се референцирани. На сликите има некои преопшти функционалности, треба да се конкретизира која точно функционалност на кого реално му треба.

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

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

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

Организации

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

Поединци

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

Корисници

• Корисничко име
• Лозинка

Услуги

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

Врски

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

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

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

ЕР дијаграм

Направете ЕР дијаграм со софтверот TerraER, прикачете ги како атачменти и самиот изворен XML документ од дијаграмот и експортирана слика од дијаграмот како JPEG. Потоа линкувајте ја сликата да биде видлива тука.