Diagram przepływu danych

0

Dzień dobry. W tym semestrze na uczelni po raz pierwszy mam zajęcia z Inżynierii oprogramowania i mamy do zrobienia projekt. Moim tematem jest przychodnia lekarska. W tej przychodni pacjent nie pełni żadnej roli w systemie. Rejestruje się on poprzez kontakt z pielęgniarką, a ona wprowadza to do systemu. Jestem na etapie tworzenia diagramu przepływu danych. Zrobiłem już diagram systemowy- bez pacjenta, bo w systemie nic nie robi. Jednak coś nie dawało mi spokoju, bo przecież bez pacjenta nie odbyła by się rejestracja. Ale jak go tam umieścić skoro nie ma on dostępu do systemu? Zapytałem o to moją prowadzącą (jest bardzo młoda, świeżo po studiach), która powiedziała żebym po prostu połączył ze sobą dwa terminatory (pacjenta i pielęgniarkę). Ale z tego co mi wiadomo nie można połączyć ze sobą bezpośrednio dwóch terminatorów... W internecie praktycznie na każdej stronie jest taka informacja. Macie może jakieś propozycje?

Diagram znajduje się w załączniku.

0

Pacjent inicjuje reakcję, więc masz "przyjście do szpitala", "rejestracja na wizytę", "wejście do gabinetu", etc. Niekoniecznie piszesz taki system, ale zobacz sobie jak to jest opisane w profesjonalnym standardzie, zwłaszcza interesuje Cię pole status.

0

W diagramach przypadków użycia łączyłem pacjenta z systemem. Miałem tam np. funkcję "Rejestracja pacjenta" i łączyłem ją z pielęgniarką oraz z pacjentem. I w scenariuszach rozpisałem to, że przychodzi pacjent, podaje pielęgniarce termin wizyty, pielęgniarka wybiera ten termin w systemie, system sprawdza czy termin jest wolny itd, itp... Jednak teraz mam problem z przedstawieniem tego na diagramach przepływu danych. I nie wiem czy mam zostawić to tak jak jest w załączniku, czy zrobić to tak jak radziła prowadząca, czyli połączyć 2 terminatory ze sobą (mimo, iż jest to zabronione), czy zrobić to jeszcze inaczej?

0

Starasz się zawrzeć cały system na jednym diagramie. To błąd.

Co oznaczają te cyferki przy funkcjach systemu?
Jeśli to co powinny to System zaczyna pracę przez Rejestracji pacjenta, a kończy na Uaktualnieniu gabinetu.

Praca systemu może zaczynać się od członków systemu. Czyli wprowadzenia/pobrania danych przez pielęgniarkę, lekarza, administratora ... .

Czy jesteś pewny, że jest to UML?

0

@woki: Diagram przepływu wewnątrz rejestracji właśnie zrobiłem. Mógłbyś zerknąć czy jest w miarę dobrze ułożony?

0

Punkty 1.3 oraz 1.4 to osbny przypadek. Brak komunikacji z pielęgniarką (osobą z rejestracji).
Czyli dane pacjenta pojawiają się z nikąd.

1.1 i 1.2 dobrze, ale możesz uprościć sobie życie w ten sposób, że osoba rejestrująca(pielęgniarka) dostaje listę gotowych wolnych terminów. Chociaż można przyjąć że osób w rejestracji jest więcej, wtedy ten przypadek miałby duży sens.

1.1 powinno się łączyć z 1.5, a 1.5 z wizytami.
1.5 powinno mieć numer 2 (Dodaj do grafiku) - co z lekarzem?

Numer 3 (poinformuj o pomyślności rejestracji) - co z lekarzem?

Warto rysować takie diagramy "od góry do dołu", chociaż nie jest to jakaś mocna zasada.

Zrobiłbym to calkowicie inaczej, ale staram się dopasować z tymi podpowiedziami do tego, co zapewne mieliście na zajęciach.

0

Myślałem, że ten punkt 1.3 i 1.4 to nie jest osobny przypadek, ponieważ punkt 1.4 był extendem do rejestracji pacjenta. Założenie było takie, aby system sprawdzał przy rejestracji czy pacjent posiada kartę pacjenta. Pielęgniarka wprowadza termin i lekarza do systemu, system sprawdza czy możliwa jest rejestracja. Jeśli tak, to system wyświetla formularz rejestracyjny, gdzie pielęgniarka wprowadza dane pacjenta, następnie system sprawdza czy pacjent z takimi danymi posiada kartę pacjenta w przychodni, jeśli nie to zakłada mu tą kartę, jeśli posiada to rejestruje go. No i potem system dodaje pacjenta do grafiku lekarza (system wysyła mu powiadomienie, że pacjent został do niego zarejestrowany) oraz informuje pielęgniarkę, że pacjent został zarejestrowany.

Dodanie do grafiku miałem najpierw jako osobny proces, ale potem spojrzałem jeszcze w swoje scenariusze i "zapisanie wizyty do grafiku lekarza" miałem przy rejestracji, w głównym scenariuszu.

0

Przespałem się z tym wszystkim i postanowiłem zrobić też taki bardziej ogólniejszy diagram, tak jak mi radziłeś. Diagram szczegółowy też troszkę pozmieniałem, założenie karty pacjenta potraktowałem jako osobny proces (zastanawiam się tylko czy może tak być jeśli był to extend do rejestracji :/). Postanowiłem dodać również tego nieszczęsnego pacjenta, ponieważ dowiedziałem się od prowadzącej, że MUSZĘ go uwzględnić. Co prawda nie można go połączyć bezpośrednio z systemem, bo nie ma do niego dostępu, ale muszę go połączyć z pielęgniarką i lekarzem, bo jednak pełni on jakąś rolę...
Jeśli chodzi o lekarza i jego połączenie z wizytami, zostawiłem to tak jak było. Faktycznie można by zrobić to lepiej dodając mu np. funkcję sprawdź grafik i dopiero wtedy system pobierałby z magazynu danych Wizyty jego grafik. Jednak nie uwzględniłem takiej funkcji w przypadkach użycia, a wg tego mamy robić te diagramy (zostało to już sprawdzone). Dlatego zostanę przy tym, że po pomyślnej rejestracji system informuje lekarza, że pacjent został zarejestrowany (mam nadzieję, że nie łamię tutaj żadnych reguł co do tworzenia takowych diagramów).

W załącznikach znajdują się wszystkie diagramy, które zrobiłem: diagram kontekstowy, diagram systemowy, diagram szczegółowy oraz diagram szczegółowy dla procesu 1, czyli rejestracji. Jeśli byłby ktoś tak miły i znalazł chwilę czasu na sprawdzenie czy można to zostawić tak jak jest? Czy jednak nie obejdzie się bez zmian... W poniedziałek muszę oddać tą część projektu.

0

W praktyce rzadko kiedy widuje się takie diagramy.
Widziałem je w dwóch przypadkach, jako pomocny diagram, który do niczego nie służył oraz diagram przy sprawdzaniu końcówek bezpieczeństwa dla aplikacji.

Zazwyczaj przypadki projektowania z jakimi się spotkałem wyglądały w ten sposób:

  1. Przypadki użycia klient/wymagania dziedziny
  2. Diagramy aktywności (aby odfiltrować niedorzeczności projektowe)
  3. Diagramy klas
  4. Diagramy interakcji - dla pewnych części systemu
  5. Budowanie aplikacji - zmiana diagramów od 1-4 (najpierw szkielet, potem reszta).
  6. Testowanie końcowe aplikacji, testy bezpieczeństwa (tutaj diagramy DFD) - aby można było ogarnąć jakie dane i w jaki sposób, poruszają się po systemie i aby nie testować rzeczy, które tych testów nie wymagają. W tym miejscu jest to bardzo pomocne ponieważ, testy interakcji czasami bywają bardzo trudne i zaskakujące w wynikach. Diagramy takie wyglądają trochę inaczej niż te prezentowane przez Ciebie.
  7. Uzupełnienia, diagramy wdrożenia, powrót do punktu 6.

Poziom akademicki chyba sporo różni się od tego realnego. Możliwe też, że przeskoczyłem za mało firm, aby mieć o tym pojęcie.

Z mojej perspektywy diagramy powinny wyglądać podobnie do tego. Z kilkoma uwagami.

  1. Diagramy poglądowy nie powinien rozbijać bazy danych, od tego jest inny typ diagramu.
  2. Jeden przypadek wyizolowany na jeden diagram, bo inaczej robi się bałagan.
  3. Includy na osobnych diagramach, extendy wiadomo jako opcja więc można dodać. Dodawanie pacjenta do systemu to Include nie extended.
  4. Rozbicie bazy danych (w rejestracji) na odpowiednie części - zwyczajnie nie bawiłem się z tym na prezentowanym diagramie.

Twoje podejście przypomina "cięcie poziome systemu". Co jest bardzo negatywne, ponieważ jedna mała zmiana może zmienić Tobie dużą ilość diagramów.
Diagramy aktywności często, buduje się na torach. Stąd wyrażenie cięcia poziomego, ponieważ przecinasz te tory działania systemu. Dlatego też gdzieś wyżej wspomniałem o tym, że najpierw powinny być wprowadzane diagramy aktywności.

To jest tylko moja opinia na ten temat. Możliwe że to jakaś nowa metodologia, której nie ogarniam.

2
woki napisał(a):

To jest tylko moja opinia na ten temat. Możliwe że to jakaś nowa metodologia, której nie ogarniam.

Tak tytułem uzupełnienia, to jest jedno z dwóch popularnych podejść do analizy, zwane "analizą strukturalną", w którym to podejściu modelowane są:

  • funkcje systemu (diagramy DFD - w uproszczeniu procedury operujące na danych)
  • dane systemu (diagramy ERD - encje, atrybuty, związki między encjami)
  • dynamika systemu (diagramy STD - jak zmienia się stan "czegoś" pod wypływem zdarzeń)

Innym podejściem jest analiza obiektowa, gdzie wykorzystuje się diagramy BPMN/UML.

1

@woki: Jest kung-fu północy i południa, różne style mogą się ze sobą ścierać i rywalizować o prymat. Podobnie z podejściem do analizy :-)

W sieci masz trochę materiałów na ten temat, np. tu znajdziesz parę slajdów wyjaśniających.

Analiza strukturalna jest po prostu inną techniką niż analiza obiektowa. W AS dzieli całość na mniejsze części po funkcjonalnościach, a w OOA masz dzielenie na mniejsze części po konceptach (klasach obiektów). Problemem w strukturalnej może być to, że jeśli funkcjonalności nie są dobrze zdefiniowane, to zaczynasz od niestabilnych fundamentów, przez to ryzyko porażki z taką analizą jest większe (wydłuża się czas pracy nad systemem, a późne zmiany mogą być problematyczne). Możliwe (kwestia subiektywna), że na plus strukturalnej można zaliczyć prostszą notację (dużo mniej typów diagramów i typów elementów per diagram niż w UML).

Mnie podejrzane wydaje się mieszanie analizy strukturalnej z obiektową i produkowanie diagramów trochę zgodnych z OOA, a trochę z SA. Taki brak konsekwencji w podejściu i być może nieznajomość rzemiosła.

0

Chyba rozumiem.
Z tym, że ERD jest wykorzystywany w projektach które podałem, a STD przypomina mi diagramy maszyny stanowej (chyba tak to się nazywa).
Jak dla mnie kością niezgody są tutaj właśnie DFD, ponieważ przepływ danych pomiędzy przypadkami użycia wydaje mi się mało praktyczny. Muszę chyba pochylić się nad temat i zbadać go dogłębniej ;)

@yarel, wracając do tematu, czy mógłbyś zatem, o ile posiadasz chwilę, zobaczyć diagramy autora i ewentualnie moje oraz wypowiedzieć się czy są chociaż podobne do tego co znasz :)
Te które rysowałem są podobne(mniej rozbudowane, mniej konkretyzujące) do diagramów "testów", które znam z praktyki.

Przypomina mi się aplikacja na noudzie, która miała inny typ diagramów(to nie były UML), ale znowu nie są podobne do tego (oprócz ERD). Możliwe, że inny zakres funkcjonalności (aplikacja rozliczająca) miała wpływ na wygląd diagramów.

0

@annonymouzinho:

Zapytałem o to moją prowadzącą (jest bardzo młoda, świeżo po studiach), która powiedziała żebym po prostu połączył ze sobą dwa terminatory (pacjenta i pielęgniarkę). Ale z tego co mi wiadomo nie można połączyć ze sobą bezpośrednio dwóch terminatorów...

Masz rację. Z zasad tworzenia diagramów DFD to nie ma prawa nastąpić przepływ bez procesu uczestniczącego w przepływie, więc wszystkie przepływy Pacjent <-> Lekarz, albo Pacjent <-> Pielęgniarka nie są poprawne. Jeżeli się dzieją poza systemem, to po co miałyby być na diagramie DFD systemu? Pacjent nie wchodzi w interakcję z systemem, więc nie jest potrzebny w ogóle.

Oczywiście, że bez pacjenta to wszystko nie ma sensu, ale rolą DFD jest opisanie wszystkich przepływów informacji tylko wewnątrz systemu i do jego końcówek.

Ale!

Z praktycznego punktu widzenia, jeżeli odejdziemy od dogmatycznego traktowania zasad tworzenia diagramów na rzecz sensownej dokumentacji, to dodanie przepływów między obiektami zewnętrznymi ma sens - aby lepiej opisać o co chodzi. W końcu dokumentację i diagramy tworzymy dla ludzi, którzy to będą implementować. Gdybyś mi wytłumaczył w taki sposób jak tutaj dlaczego zrobiłeś takie przepływy, to bym prawdopodobnie zaliczył taki diagram jako poprawny ;-)

Za to z innych rzeczy:

  • czy magazyny danych nie muszą mieć identyfikatorów?;
  • Diagram 4 - proces 1.1.1 odczytuje dane z magazynu "Godziny pracy", a na diagramach poziomów wyższych nie ma takiego przepływu?
  • w ogóle posprawdzaj strzałki, bo mam wrażenie, że na poziomach niższych masz odczyt, a na wyższych zapis albo odwrotnie.

@woki:

Jak dla mnie kością niezgody są tutaj właśnie DFD, ponieważ przepływ danych pomiędzy przypadkami użycia wydaje mi się mało praktyczny. Muszę chyba pochylić się nad temat i zbadać go dogłębniej ;)

Zasadniczo DFD nie opisują przepływu pomiędzy przypadkami użycia, a między procesami, które nie do końca muszą im odpowiadać :)

1 użytkowników online, w tym zalogowanych: 0, gości: 1