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 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0