Вишок или недоволно дефинирани системски случаи на употреба

[Vangel Ajanovski]

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

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

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

[Vangel Ajanovski]

Сега забележав дека во дијаграмите е ставено дека менаџира настани и менаџира корисници се дел од одржува база, но тоа не е доволно јасно наведено во самите документи на овие случаи на употреба, а не е јасно ни во главниот од нив. Воедно користено е include што кажува дека во секое одржување на база се прави и менаџирање настани и менаџирање корисници, не е наведен редослед на истото во документите, а и се сомневам дека на секое седнување се прават сите тие работи наеднаш. Секое од нив е веројатно посебна ситуација и се случува во одделен момент со одредена цел, а не сѐ на куп.

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

[111063]

Го сменивме дијаграмот, наместо include сега е еxtend.
Одржува сервер го избришавме.

Одржува база на податоци се случува кога има некаков проблем, пример треба д аму се забрани пристап на некој корисник, или пак има некој корисник што мора да се избрише бидејќи правел проблем. Друг случај би било ( за менаџира настани) кога некој организатор неможе да се снајде најдобро со системот, или пак направил некаква грешка при внесување на билети или нешто слично во врска со некој настан. Бидејќи тој нема пристап за го менува бројот на билетите откако се внесени, или пак има проблем со кодовите( кликнал да се генерираат автоматски а се премислил и сака рачно), и сл...
Мислевме дека нема начин да се престави некаква причина за ова да се случи и затоа го сотавивме така.

Како би можеле да го претставиме тоа во Use case дијаграм, дека потребно е или проблем со корисник или проблем со некој организатор за да се случи овој кориснички случај?

[Vangel Ajanovski]

• Јас сеуште го гледам Одржува сервер како случај на употреба во моделот, и дури има и дијаграм за

него. Можеби не сте ги испратиле последните промени.

• Со самото тоа како сте го напишале горниот коментар за Одржува база, вие самите велите „се случува“, „друг случај“, ... значи тоа се посебни случаи на употреба на системот кои ви се важни и треба да ги имате предвидени и во моделот и во текстот. Поминете уште една итерација во размислување за вакви дополнителни испуштени случаи и наведете ги.

[113039]

Одржува сервер сега дефинитивно е избришан од моделот.

Во 'Одржува база' каде што се вклучени и 'Менаџира корисници' и 'Менаџира корисници' од истите тие сега прават extend ново додадените случаи на употреба 'Доделува привилегии', 'Бришење на корисник' и 'Уредување на настан' кои се најбитните случаи од страна на администраторот кога се случува нешто ново односно прави промена во базата на податоци.

[Vangel Ajanovski]

За одржува сервер е во ред.

За одржува база, го гледам UCD и таму е во ред, иако мислам дека тие не треба да се екстензии на „Одржува база“ туку да се самостојни и независни кориснички случаи.

Дискусијата за одржување база, дека може да постојат и непредвидени ситуации кога треба нешто да се направи директно во базата, како некоја општа работа во базата, е во ред и тоа може да биде самостоенслучај на употреба, а овие да се екстензии, но мислам дека во општиот дел треба да има и некакви податоци за тоа што точно се барало и што е направено, на пример по чив налог и за кои причини е промената директно во базата, кога тоа е направено, кој го направил, па дури можеби и лог на сите наредби за измена извршени во базата, како дополнителна контрола. Инаку како што веќе дискутиравме, се отвора пат за администраторот да си прави што и кога ќе посака директно во базата, што не е баш добра пракса.

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

Средете го ова и ќе биде во ред, испратете нова верзија и затворете го тикетот.

[111063]

Додадовме во Description делот.