Forum jest naprawdę super. Jeszcze wczoraj prawie nic na tema UMLnie wiedziałem nic (teraz za duż tez nie wiem) a dzisaj mam już jakiś diagram .

Niestety jako nowicjusz płacę frycowe i dalego proszę o ile to mozliwe o sprawdzenie mojego modelu
Czy ide w dobrym kierunku, moze robię coś nie tak.

UML wykorzystuje do analizy biznesowej. Potem dopiero planuje wyprowadzić system inf.
Na wszelki wypadek żeby czegoś nie pomylić będę używałem nazwnictwa z programu EA.

Zrobiłem wiec wpierw primary use case na poziomie abstrakcyjnym.
Następnie na (na razie do jednego przypadku) zrobiłem i podłączyłem w EA Activity Diagram
Przypadek do, którego zrobięł Activity Diagram to Zarządzanie zamówieniem klienta.

Na dole ukazałem obydwa diagramy

Aby było wiadomo o co chodzi zrobiłem opis „słowni muzyczny”  do tematyki, któą opsiuje.
Opis znajduje sie po diagramami.


Od razu nasuwa mi się kilka pytań.
1. Dla przypadku Zarządzanie zamówieniem klienta zrobiłem Activity Diagram - w diagramie tym naniosłem równiez przypadek zmiany zamówienia przez klienta i kosekwenjci z tym zwiazanych. Czy powinienm to robic na tym samym Activity Diagram. Czy robi się drugi diagram dla tej sytuacji a moze to zupełeni inny przypadek
2. Czy słuszenie zrobiłem przypadek Generowanie raportów? Może zamiast tego powinien być przypadek Kontrola realizacji zamówień? A może dodatkowo powinienem stworzyć przypadek Kontrola realizacji zamówień?

Proszę o pomoc. Cheteni wysłucham wszelkiej krytyki i sprobuje wyciągnąć wnioski.


OPIS procesu/obszaru zwiazanegoi z realizacją zakupów zaopatrzeniowych.(Opis ten zawiera w sobie wszytskie przypadki, które ukazałem na diagramie use case)
(Tu też mam mały dylemat czy to co opisałem to jest jeden proces czy kilka ???)

Klient zamawia w firmie okreslone pozycje asortymentowe. Firma nie tworzy zapasów tylko specjalnie na zamawia towar na rzecz klient kupuje je u dostawcw,

Omawiany proces rozpoczyna zamówienia klienta. Po jego otrzymaniu jest ono wstępnie weryfikowane przez kierownika. Jęsli kierownik uzna , że jest niekompletne lub nda się go zrealizować to odrzuca go klienta , który może po skorygowaniu zamówienia ponownie je przesłać.
Jeśli zamówienia zostanie przyjęte kierownik je rejestruje. Następnie rozdziela poszczególne pozyceje asortymentowe na handlowców, którzy będą je zamawiali u dostawców.
Kierownik powiadamia handlowców o ich pozycjach na zamówieniu. Handlowcy weryfikują swoje pozycje zamówienia. Jeśli nie maja zastzreżeń do przypisanych im pozycji przyjmują je do realizacji. Mogę też poprosić o przypisanie do otrzymanych pozycji zamówienia innych handlowców Jeśli kierownik przychyli się to zmiany to poprawia daną ;pozycję zamówienia w ten sposób, że przypisują tam innego handlowca.
Handlowcy realizuje swoją część zamówienia klienta poprzez składanie zamówienia u dostawców oraz dokonywanie zakupów osobiście u dostawców. Zakupy dokonywane osobiście przez handlowców realizują oni ma podstawie sporządzanych przez nich list zakupów. Handlowcy przygotowują zamówienie do dostawcy oraz listę zakupów realizowanych osobiście przez handlowca. Przygotowaną w ten sposób lista zakupów lub zamówienie jest rejestrowane i drukowane. Zamówienie jest wysyłane do dostawcy. Jeśli dostawca potwierdzi zamówienie, to handlowcy odnotowują na pozycjach zarejestrowanego zamówienia do dostawcy ten fakt.
Zamówione towary dostarczane są do magazynu, gdzie oczekują na odbiór celem dostarczenie do klienta.. Magazynier ma dostęp do zarejestrowanyxch i potwierdzonych zamówień dostawców, które mają przyjść do magazynu. Przyjmując towary od dostawców sprawdza ze zarejestrrowanym przez handlowca zamówieniem. Magazynier rejestruje dokumet przyjęcia towaru (PZ) i go drukuje , na którym odzwierciedla stan przyjetych pozycji i nanosi ewntualne uwagi o wadach i brakach. W sytuacj wydania towary rejestruje dokument wydania zewnętrznegoi (WZ) go drukuje.
Handlowiec ma dostęp do stanu magazynowego i odczytuje ewntualne uwagi magazyniera z przyjęcia dostawy. Jeśli z uzyskanych informacji wynika, że w dostawach są braki lub wady to przygotowuje reklamację do dostawcy
Kierownik przeprowadza na bieżąco kontrolę realizacji dokonanych zakupów na rzecz klienta. W tym celu sporządzany jest raport realizacji zamówienia klienta, który zawiera informacje o ilosci pozycji zamówionych przez klienta, ilości zamówionych u dostawców, ilosci zmagazynowanej. Jeśli w wyniku kontroli uzna, że zamówienie jest skompletowane to powiadamia klienta, powiadamia magazyn o możliwości wydania towaru klientowi oraz przekazuje raport obsłudze płatnosci, którzy przeprowadzają wycenę i wystawiają fakturę klientowi.
Gdy klient zgłasza zmianę w swoim zamówieniu kierownik weryfikuje zmianę i możliwość jej przeprowadzenia porównując ją z dotychczasową realizacją zamówienia. W tym celu przeprowadza kontrolę realizacji dokonanych zakupów na rzecz klienta. W tym celu sporządzany jest raport realizacji zamówienia klienta, który zawiera informacje o ilosci pozycji zamówionych przez klienta, ilości zamówionych u dostawców, ilosci zmagazynowanej Porównując ów raport ze zmianą zgłoszoną przez klienta kierownik stwierdza, czy przyjąć zmianę zamówienia.Jeśli zmiana zostanie przyjęta to aktualizowane jest zarejestrowane zamówienie klienta, przy nowych pozycjach przydzielania są handlowcy, którzy będa je realizować. Handlowcy są informowani o dokonanje przez kierownika zmianie.


Digram use case:




Aktorami biorącymi udział w use case są:
 Klient - składający zamówieniei odbierajacy towar
 Kierownik- szef handlowców;
 Handlowcy - odpowiedzialni za realizację części zamówienia klienta przypisanej im przez kierownika;
 Magazynier - obsługujący magazyn;
 Dostawca - realizujący zamówioną dostawę.

Przypadki w primary use case
Zarządzanie zamówieniem klienta - Funkcje związane z obsługą zamówienia klienta. Przyjęcie zamówienia, werfyfikacja zamówienia, przydzielenie do pozycji zamówienia handlowców, którzy w dlaszej kolejności będą realizowali zakupy na rzecz przypisanych im pozycji.
Zarządzanie zamówieniami do dostawców - Zajmuje się sporządzaniem zamówienia do dostawców, kontrolą zamówienia dostawcy z przyjętą przez magazyniera dostawą, reklamacją zamówionych pozycji
Zarządzanie magazynem - Zajmuje się przyjmowaniem dostaw, wydawaniem towaru,kontrolą przyjęć i wydań towaru, sporządzaniem dokumentacji magazynowej,
Generowanie raportów - sprawozdania kontrolne przedstawiające realizację zamowienia klienta, grupowane wg klientów, zamówień, handlowców. Przedstawiają stan zamówienia, zamówione pozycje u dostawców, potwierdzone przez dostawców, zmagazynowane w mgazynie.
Dodatkow Listy zakupów., zamówienie do dostawcy.



Diagram Activity Diagram dla - Zarządzanie zamówieniem klienta







Dzieki z gory za pomoc
netpagowski

Witaj,
Dużo treści, nie wiem, jak zacząć odpowiadać.
UML nie jest metodyką. Widzę, że posługujesz się metodyką RUP. Bardzo dobrze. Zaczynasz prawidłowo - od diagramu przypadków użycia. Z tym, że ten, co robisz nie jest tak naprawdę biznesowym przypadkiem użycia. Notacja jest ok., ale funkcje dotyczą systemu. Modelowanie biznesowe ściśle dotyczy samej organizacji np. dokonywanie zakupu, odbiór towaru, składanie zamówień, prowadzenie statystyki firmowej. Twój diagram dobrze oddaje etap modelowania wymagań funkcjonalnych. Wtedy aktorów dzieli się na zewnętrznych i wewnętrznych (pracowników organizacji). Oprócz tego mam tu kilka uwag.:
1. Przypadek Generowanie raportów może być jak najbardziej, z tym, że może być powiązany z pozostałymi rozszerzeniem extend (związkiem rozszerzającym o grocie skierowanym do rozszerzanego przypadku uzycia np. zarządzanie...)
2. Przypadki typu Zarządzanie itp.: to są przypadki typu CRUD - warto myślę to zaznaczyć. (Create, Re..., Update, Delete) - drugiego nie pamiętam.
3. Diagram biznesowy wymaga ściśle użycia biznesowych przypadków użycia, biznesowych aktorów - patrz kilka wierszy wyżej.
4. Klient, Dostawca, System płatności nie obsługują magazynów, ani innych funkcjonalności. Tu powinny być relacje bezpośrednie.
5. Diagramy czynności / aktywności oraz/lub diagramy interakcji (sekwencji, komunikacji) powinno się robić na każdym poziomie raczej pod każdy przypadek użycia. Są to niejako scenariusze ich realizacji.
Jak będę miał uwagi to jeszcze dopiszę. Jak coś, to proszę pisać

----------------
Pozdrawiam
Jacek
[email protected]
http://prog.kosmos.clubnet.pl
skype: jacek.achtelik lub jacekachtelik (Proszę na to pierwsze zostawiać wiadomości).
GG: 2768721
(radzę kontaktować się na Skype'a lub emailem - za GG nie przepadam :) )

Dzieki za cenne uwagi.
Ale im dalej w las tym ciemnie. Co raz więcej pytań mi się nasuwa.
Na początek poprawiłem use case na biznesowy jak mi się wydaje.




Aby łatwiej zrozumieć co ja tu "tworzę" w paru słowach objaśnie przypadki użycia.

Przyjęcie zamówienia - czynności zwiazane obsługą zamówienia klienta. Przyjęcie zamówienia, zmiany zamówienia, werfyfikacja zamówienia, przydzielenie do określonych pozycji zamówienia handlowców, którzy w dalszej kolejności będą realizowali zakupy na rzecz przypisanych im pozycji. Ten przypadek uruchamia przypadek Realizacja zakupu

Realizacja zakupu - czynności obejmujące: analizę zamówienia klienta pod kątem realizacji zakupów pod to zamówienie, analizą ofert dostawców, przygotowaniem zamówieniem i sporządzaniem zamówieniem do dostawców, przygotowaniem listy zakupów dla handlowca(jeśli sam dokonuje zakupów),
Obejmuje równieź czynności związane z weryfikacją realizacji zamówienia dostawcy w konfrontacji z udokumentowaną kontrolą przeprowadzoną przez magazyniera.
Zajmuje się też reklamację zamówionych pozycji do dostawcy.


Lista płatności - tworzona jest lista płatności w przypadku zamówień, które wymagają płatności przed dostawą. Wtedy potrzebna informacja dla działu obsługi płatności.

Wydanie towaru - Wydania zamówionych towarów klientom . Wydania dostawcom i handlowcom jako zwrot. Udokumentowanie wydań.

Zamagzynowanie towaru - Przyjęcie i skontrolowanie dostaw. Przyjęcie zwrotów klientów. Udokumetowanie przyjęć.

Kontrola realizaji zakupów - obejmuje czynności związane z kontrolą relizacji zamówienia klienta. Tworzone sa m.in. sprawozdania kontrolne przedstawiające realizację zamowienia klienta, grupowane wg klientów, zamówień, handlowców. Przedstawiają stan zamówienia, zamówione pozycje u dostawców, potwierdzone przez dostawców, zmagazynowane w mgazynie.Przypadek ten odzwierciedla kontrolę całości zamowienia klienta, po pierwsze kierownik kontroluje ten stan w celu wykrywania odchyleń - musi zatem znać ilość zamowionych towarow każdej pozycji asortymentowej . ilosc zamowionego tego towary u dostawcy, ilosc zmagazynowana. Jesli stwierdzi w wyniku kontroli, ze zgromadzono wszystkie towary dla klienta, to wtedy ten towar moze byc wydany klietnow a informacje do wsytawienia faktury dostaje dział płatnosći.

Dane do wystawienia faktury - Jeśli kontrola wykaże, że zamowienie klienta zostało zrealizowane tworzona jest lista zreazliowanych pozycji niezbedna do stworzenia wyceny zamówienia klienta przez dział płatnosci..


Prosżę o odpowiedź na moje poniższe aątpliowści , jeśli się uda.

1.Maiłem watpliowśc co do aktora handlowiec i potraktowanie go jako zewnętrznego. Dlaczego go umieściłem, ponieważ handlowiec jest powiazny z realizacj zakupu i z Magzynowanie towaru., gdyż on sam od siebie otrzymuje liste zakupów jezdzi po hurtowniach , tam kupuje i dostarcza do magazynu towar.
Ale czy tak powinno być - ??????

2.Czy w sytuacji przypadku Realizacja zakupu - magznier bedzie aktorem zewnetrznym, skoro jest dawcą informacji o realizacji dostawy. Jak juz pisalem jedna z czynnosci tego przypadku bezie kontrola dostawy z dokumentacja magazynowa, ktora magzynier sporzadza.
Z tym, że dokumentacja ta jest sporzadzan przez przypadek Magzynowanie towaru. Jak na razie tego aktora jako biznesowego tu nie wstawiłem.


3. Czy przy e rzypadku kontrola Realizacji zakupów powinienem pociagnąć linię z/do przypadków uzycia Przyjęcie zamówienia, Realizacja zakupu. , Kontrola reaizaji zakupów, Dane do wystawienia faktury. Nasuwa mi się to ponieważ jakbyz tych obszarów czerpie się poniekąd (są źródłem) danych o stanie realizacji zakupionych towarów.





NA razie tyle, niedługo wrzuce do przypadków diagramy czynnosci. Mam nadzieję, że tym razem będzie lepiej.

Jeszcze raz dzieki i czekam na falę krytyki :)

Witaj,
Kilka uwag.:
1. realizacja zakupu wymaga przyjęcia zamówienia - stąd include powinien być odwrotnie,
2. realizacja zakupu pozwala na sprawdzenie listy płatności - stąd extend powinien być w drugą stronę
3. Pomiędzy wydaniem towaru a magazynowaniem towaru nie jestem pewien, czy tu musi być include, czy extend. Dałbym ten drugi i to w drugą stronę
4. Nie jestem pewien kontroli zamówień i wystawiania dokumentów sprzedaży (dwa najniżej położone przypadki użycia). Czy rzeczywiście powinny być połączone, czy nie mówią o zupełnie czym innym?
Takie są me spostrzeżenia.
Ale diagram robi się coraz lepszy.

----------------
Pozdrawiam
Jacek
[email protected]
http://prog.kosmos.clubnet.pl
skype: jacek.achtelik lub jacekachtelik (Proszę na to pierwsze zostawiać wiadomości).
GG: 2768721
(radzę kontaktować się na Skype'a lub emailem - za GG nie przepadam :) )