IS-P11-L3.pptx
- 1. 23.07.2025 П11: 1/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Добар начин да се разуме моделирање дијаграма активности јесте коришћење примера извођења система управљања болницом са претходног предавања. Разматрају четири специфична дијаграма активности који одговарају четири случаја употребе која су раније документована. Ови дијаграми активности, засновани на та четири случаја употребе, су следећи: Дијаграм активности РегиструјПацијента Дијаграм активности ОдржавајКалендар Дијаграм активности ЗакажиПреглед Дијаграм активности ПлаћањеРачуна
- 2. 23.07.2025 П11: 2/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „РегиструјПацијента“ Слика приказује дијаграм активности који представља процес регистрације података о пацијенту.
- 3. 23.07.2025 П11: 3/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „РегиструјПацијента“ Овај дијаграм почиње активношћу псеудо почетка, након чега следи активност ОбјавиДолазак. Након завршетка ове активности, ток унутар овог дијаграма активности достиже тачку одлучивања. Тачка одлучивања проверава да ли пацијент први пут посећује болницу. Пацијент који не долази први пут приказује се на дијаграму активности као да улази у псеудо заустављање, јер су подаци о том пацијенту присутни у систему. Пацијент који први пут посећује болницу покреће активност ПроведиДетаље. Контрола процеса се затим преноси на активност УнесиДетаље у Администраторској партицији. Ток затим достиже тачку синхронизације где се активности деле у две нити. Провера/Детаљи у системској партицији проверава исправност унетих података, а ПровераМедицинскоОсигурањеДетаљи у GovtHRS (Државни здравствени систем) партицији проверава податке о здравственом осигурању пацијента.
- 4. 23.07.2025 П11: 4/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „РегиструјПацијента“ Ако се ове две активности спроводе секвенцијално (једна за другом), време обраде ће трајати много дуже него ако се активности спроводе паралелно. Две активности које се одвијају паралелно се спајају у следећој тачки синхронизације. Време које је потребно свакој од ове две активности спроведене паралелно може бити различито. На пример, VerifyDetails може трајати само 30 секунди, али VerifyMedicalInsuranceDetails може трајати неколико минута. Када се обе ове активности, са различитим временским оквирима, заврше, тада може почети следећа активност. Завршетак обе ове активности у одређеном тренутку је приказан хоризонталном траком за спајање. Ово рачвање и спајање дијаграма активности олакшава оптимизацију токова посла и побољшање квалитета. Када се провери да ли су подаци о пацијенту тачни, запис о пацијенту се креира у активности CreatePatientRecord. Алтернативно, ток се преусмерава на активност ProvideDetails. Регистрација новог записа о пацијенту се потврђује у активности RegistrationConfirmed, која се затим завршава у псеудо заустављању.
- 5. 23.07.2025 П11: 5/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „ОдржавајКалендар “ Слика приказује дијаграм активности који представља процес одржавања детаља календара.
- 6. 23.07.2025 П11: 6/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „ОдржавајКалендар “ Овај дијаграм почиње активношћу псеудо покретања, након чега следи активност RequestPersonalCalendar у партицији за особље. Контрола се затим преноси на активност ProvidesPersonalCalendar у системској партицији. Следи активност EnterPreferredDetails у којој особље уноси своје жељено радно време. Ови детаљи се проверавају у активности ValidatePreferredRosterDetails и контрола достиже тачку одлучивања. У случају конфликтног календара, контрола се преноси на активност ProvideCalendarOptionsToStaff, која следи активност EnterPreferredDetails за још један скуп валидација. Ако тражени детаљи распореда нису у супротности са постојећим распоредом, детаљи се прихватају у активности AcceptDetails. Прихваћени детаљи се ажурирају у календару у активности UpdateCalendar у системској партицији. Нови детаљи календара се потврђују у активности RegistrationConfirmed, која се затим завршава у стању псеудо заустављања.
- 7. 23.07.2025 П11: 7/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „ЗакажиПреглед “ Слика приказује дијаграм активности који представља процес заказивања консултација.
- 8. 23.07.2025 П11: 8/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „ЗакажиПреглед “ Овај дијаграм почиње псеудо-почетном активношћу, након чега следи активност SpecificsInitialDetailsForConsultation у партицији Patient. Посебна напомена приложена овој активности наводи да детаље треба изабрати са листе пружених услуга. Листа лекара је дата у активности ProvidesListOfPhysician у системској партицији. Пацијент затим бира лекара у активности SelectsPhysician. Систем затим пружа доступна времена консултација за изабраног лекара у активности ProvidesAvailableConsultationDay&Times. Пацијент затим бира датум и време у SelectsDay&Time, што се ажурира у активности UpdateCalendar. Консултације могу бити кратке или детаљне. Ову варијацију није лако приказати помоћу нотација дијаграма активности – стога је приказана у посебној напомени. Потврда се приказује у активности ViewConfirmation, која се затим завршава у стању заустављања.
- 9. 23.07.2025 П11: 9/20 11. Дијаграми језика UML – дијаграм активности 11.3. Пример дијаграма активности за систем управљања болницама Дијаграм активности „Плаћањерачуна“ Слика приказује дијаграм активности који представља процес плаћања рачуна од стране пацијента. Овај дијаграм почиње псеудо покретањем активности, након чега следи активност Примањерачуна у партицији Пацијент, у којој пацијент прима рачун за све услуге. Рачун се верификује у односу на све консултације у активности ВерификујерачунУзКонсултације, а затим контрола прелази на тачку одлучивања Важи. Ако су детаљи валидни, активност Плаћањерачуна почиње и касније се завршава у стању заустављања. Ако постоје грешке у рачуну, контрола се преноси на активност Пријави грешку, која се поново завршава у стању заустављања.
- 10. 23.07.2025 П11: 10/20 1. Да ли дијаграм активности представља дијаграм случаја употребе или случај употребе? Објасните на примеру. 2. Која је сврха партиције (пливачке стазе) у дијаграму активности? 3. Нацртајте једноставан дијаграм активности, попут дијаграма тока, заснован на случају употребе. 4. Нацртајте детаљан дијаграм активности који приказује партиције, вишеструке нити и тачке одлучивања. 5. Како вишеструке нити помажу у оптимизацији токова рада? Дискутујте са примерима. 11.4. Контролна питања