Diagram przepływu danych

Odpowiedz Nowy wątek
2019-05-02 14:46
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.

  • uml.png (0,17 MB) - ściągnięć: 35

Pozostało 580 znaków

2019-05-02 16:16
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.

Pozostało 580 znaków

2019-05-02 17:11
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?

Pozostało 580 znaków

2019-05-02 17:11
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?

Jest to diagram systemowy. Nie widzę potrzeby aby rozdzielać go na mniejsze części. Cyferkami ponumerowałem sobie procesy żeby potem łatwiej się odwoływać w diagramie szczegółowym. Nie wiedziałem, że musi to być po kolei ponumerowane... To teraz już nie wiem czy pierwsza ma być rejestracja czy dodawanie pracowników. - annonymouzinho 2019-05-02 17:20
Powinieneś zmienić wszystkie te "kółeczka" na jedno kółeczko. Pielęgniarka łączy się z systemem pielęgniarek, lekarz z systemem lekarskim itd ..., a dane, czyli wizyty, karty ... łączą się z odpowiednimi "kółeczkami". Za mocno to rozdrobniłeś jeśli chodzi o funkcje dla poglądu. Jak już pewnie sobie odpowiedziałeś, pacjent raczej nie jest częścią systemu - może że go powiadamiamy. Ten typ diagramu w normalnej formie powinien raczej odwzorowywać jeden przypadek użycia (mała część systemu). Na poglądzie minimalizujesz ilość informacji. Nie podawaj mylących liczb w funkcjach. - woki 2019-05-02 17:47
Czemu mam to dzielić na 3 systemy? Przecież diagram kontekstowy powinien być jeden. W diagramie kontekstowym mam jako proces "System zarządzający przychodnią lekarską" i łączę go przepływami danych, które występują w systemie z terminatorami (pielęgniarka, lekarz, administrator). Czy naprawdę mam wszystko źle? Starałem się zrobić to jak najlepiej żeby wszystko tutaj było i o niczym nie zapomnieć... Wracając jeszcze do tego nieszczęsnego pacjenta. Czyli rozumiem, że nie musi go tutaj w ogóle być? Skoro pielęgniarka kontaktuje się z nim poza systemem - annonymouzinho 2019-05-02 18:05
Nic takiego nie napisałem o jakimś dzieleniu. Punkty (1,2,3) z Twojego diagramy po prostu powinny być jako jedno: "Rejestracja", natomiast (12,13,14,15,16) jako "Panel administratora" itd.. .Oczywiście jeśli to ma być pogląd systemu. Punkt 17 to ogólnie jakieś nieporozumienie. Czyli pielęgniarka idzie do lekarza i uaktualnia mu godziny pracy? Jeśli pacjent nie "dotyka" systemu, czyli ma przed sobą lekarza, pielęgniarkę to nie powinno go być na diagramie. Diagram fajnie już podzieliłeś. Jak sama nazwa wskazuje, jeśli to pogląd to powinno się łatwo "przyjąć". - woki 2019-05-02 18:15
Faktycznie jeśli chodzi o punkt 17 trochę odleciałem. Dopiero pojawi się on na szczegółowym diagramie. Chodzi w nim o to, że jeśli administrator przydziela godziny pracy pielęgniarce czy lekarzowi, to system poinformuje ich o tym. Chyba, że źle to sobie wymyśliłem. No i niestety nie mogę złączyć tego tak żeby było to bardziej czytelniejsze. Też najpierw chciałem zrobić coś w stylu "Ewidencja wizyt", ale okazało się, że ma to być jednak bardziej szczegółowe. - annonymouzinho 2019-05-02 18:20
Na Twoim miejscu zrobiłbym pogląd, taki jak Ci napisałem. Do tego poglądu dołączyłbym (na osobnych diagramach), przypadki użycia tak jak masz podzielone. (1. Rejstracja pacjenta). Z tego można już wykonać diagram przepływu z kolejno (ponumerowanymi) wykonywanymi zadaniami wewnątrz. Tak jak przyjęcie danych od pacjenta, sprawdzenie danych, dodanie do listy pacjentów ... . Najlepiej dopytać się prowadzącego czego oczekuje. Na studiach lepiej pytać niż wróżyć :) - woki 2019-05-02 18:41

Pozostało 580 znaków

2019-05-02 19:19
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?

Pozostało 580 znaków

2019-05-02 19:53
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.

Pozostało 580 znaków

2019-05-02 20:06
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.

Chodzi mi tutaj bardziej, o to że lekarz powinien mieć jakieś konkretniejsze połączenie z systemem. Zakładanie karty oraz dokonywanie rejestracji to różne procesy. Możesz go dodać ale chyba nie powinieneś go rozpisywać. Dlatego że dotyczy on innych części systemu. Może jestem starej daty, ale jeśli pisaliście przypadki użycia dla części systemu, to czemu nie robicie teraz diagramów aktywości tylko DFD? Przejście z aktywności do DFD byłoby bardziej proste. - woki 2019-05-02 20:38
Chyba rozumiem o co Ci chodzi. Faktycznie nie powinienem rozpisywać procesu Założenia karty pacjenta w tym miejscu. Jeśli chciałbym to rozpisać to musiałbym stworzyć osobny diagram gdzie zdekomponowałbym sam ten proces. Czyli te procesy będą mogły zostać, tak? Bo trochę dziwnie mi to tak rozdzielać, skoro sprawdzenie przez system czy istnieje karta pacjenta jest częścią rejestracji. Ogólnie to projekt mamy podzielone na 3 części, które oddajemy na bieżąco i są one sprawdzane. Pierwszą częścią były przypadki użycia, scenariusze, teraz robimy drugą - diagram dfd, erd - annonymouzinho 2019-05-02 21:50

Pozostało 580 znaków

2019-05-03 11:55
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.

Pozostało 580 znaków

2019-05-05 22:09
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.

edytowany 1x, ostatnio: woki, 2019-05-05 22:12

Pozostało 580 znaków

2019-05-06 09:27
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.

Dzięki za informację :) Koleje losu, przez tyle lat nie trafiłem, a za czasów jak studiowałem nie mieliśmy czegoś takiego. Czy mógłbyś napisać w jakich konkretnie przypadkach wykorzystuje się to podejście? - woki 2019-05-06 10:27

Pozostało 580 znaków

2019-05-06 10:59
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.

Pozostało 580 znaków

Odpowiedz
Liczba odpowiedzi na stronę

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

Robot: Xenu Link Sleuth (2x)