Projekt portalu wymiany usług

Witam

Zamieszczone screeny odnoszą się do systemu wymiany usług. Jest to coś w rodzaju oferii. Wymiana usług bez użycia gotówki czy

przelewów. Na razie są to wstepne szkice i nie jestem pewien na ile dobrze rozumiem podstawy projektowania tego typu systemów.
Zapewne jest tu nieco błędów i niedociągnięć. Gdyby ktoś doświadczony mógłby skomentować to w pewien sposób. Dodaj sugestie byłbym
wdzięczny ;)

Przestrzeń, w jakiej to sporządziłeś, jest zupełnie niejasna.
Czy to jest przepływ kolejnych czynności biznesowych (document flow), czy spisy menu, czy jeszce coś innego nie wiadomo

na tym etapie "dobre chęci", niby wszystko a prawie nic

EDIT i jeszcze te extends / INCLUDE ????
Projekt kodowania ? Co za include ?????

tutaj nic nie jest poprawnie, poczytaj najpierw jak to powinno wygladac a potem sie za to zabier

Nie znam się, ale się wypowiem… ;)

• Nazwy zdjęć nie odpowiadają procesom. Np. na zdjęciu “register.jpg” są wyliczone czynności nie tylko dla rejestracji. Ale i inne zdjęcia też.
• Strzałki o przerywanej linii (“include”, “extends”) nieraz błędne i służą do ukrywania faktycznych zależności, czasem są odwrotnie wskazujące (np. w “dodawanie_uslugi_proces.jpg”). Moim zdaniem mogłoby zostać tylko “include” bez nazwy, które oznaczane byłoby przez przerywaną linię strzałki, “extends” to jakaś pomyłka ukrywająca faktyczne procesy.
• Pokazane schematy są tylko ogólnymi funkcjonalnościami, które mogłyby być zaimplementowane, nie są procesami.

AnyKtokolwiek napisał(a):

Przestrzeń, w jakiej to sporządziłeś, jest zupełnie niejasna.

W 100% tak

overcq napisał(a):

Nie znam się, ale się wypowiem… ;)

• Nazwy zdjęć nie odpowiadają procesom.

Bo się nie znasz ;)
Skąd wiesz, że to miało obrazować procesy?

Widać w tym jakieś rzeczywiscie "dobre chęci", ale totalny mischung

@overcq:

Jakim kluczem należy wg Ciebie rozumieć "include" i "extends" w schematach tego rodzaju ?
Przyjmijmy hipotetycznie, że rodzaj tych schematów jest jakiś określony

@AnyKtokolwiek:
“Include” to jest funkcjonalność zawarta w czynności. Widać to najlepiej w “edycja_konta.jpg” dla strzałek “include” tylko pierwszego poziomu. “Extend(s)” to jest pewnego rodzaju ukrycie/uniknięcie definiowania procesu dla nowej czynności przez oznaczenie, że jest jakaś czynność, która jest rozwinięciem tej źródłowej. Wydaje się też, że nazwy te pochodzą z przestrzeni przyszłego kodu, gdzie elementy “include” byłyby wewnątrz procedury (np. na jednym formularzu), a elementy “extend(s)” byłyby możliwe do uzyskania wywoływaną procedurą (np. przyciskiem z formularza). Natomiast ogólnie na tych schematach są pomieszane kierunki strzałek i przypisania.

@overcq:

@AnyKtokolwiek sugerował, ze to przenikanie kodu do rzekomo abstrakcyjnego "projektu"

Dodam, że o ile extends sugeruje ujęcie obiektowe (???) to include już tylko wymioty przy JSP

Tak, jeśli przy robieniu projektu koncepcyjnego (cokolwiek by to znaczyło) już silnie myślimy kodowaniem, braknie koniecznego dystansu, od-abstrahowania się, i "projekt koncepcyjny" wychodzi niskich lotów.

W pratyce bywa jeszcze gorzej, MAMY JUŻ kod, pół biedy jak z ciekawości / proof of concept napisany do tego projektu 1), gorzej jak kod jest wyniesiony z innego, zupełnie w co inne wymierzonego projektu
Zwykle graficzny projekt jest wtedy zbędny (w ogóle często jest zbędny), a służy zaspokojeniu pozamerytorycznych kompleksów / narzuconych spsoobów korpomyślenia, w rodzaju "schemat graficzny musi być"
Obok jest watek bazodanowy, gosciu ma 2000 tabel i chce programu który to graficznie pokaże.

1. proof of concept po to jest jest PoC, aby bez płaczu poszedł w kosz

Pierwszy diagram, co to jest za aktor "system"? Aktor powinien przedstawiać coś (użytkownika, zewnętrzny system), który nie jest częścią tego co modelujesz, ale dokonuje jakichś tam interakcji poprzez UI/API.
Brakuje też możliwości zamówienia wyszukanej usługi.

Na początku nie wiedziałem czy system zawrzeć jako aktora pośredniczącego w procesach czy też jako granice obszaru działania systemu.

Jeśli chodzi o relacje include to chciałem za jej pomocą ująć tutaj pewne pojedyncze procesy bez któryc proces głowny były niemożliwy
do realizacji aczkolwiek wedle tego co piszą ksiażki bardziej może chodzic o jeden dość ,,stały" proces/scenariusz który możemy użyć w
innych przypadkach użycia.

Nie wiem co mam rozumieć przez różnicę między procesem a funkcjonalnością. Choćby rejestracja numeru w systemie może być zarówno jednym
jak i drugim chyba, że się bardzo mylę.

To co sporządziłem jest wstępnym zarysem scenariuszy które rozwiązują problem wymiany usług między zarejestrowanymi użytkownikami.
Ew któryś pokusi się o wypunktowanie błędów lub poprawki na schematach niekoniecznie czerwonym kolorem.

Kolejna kwestia w tym wszystkim jest to , że nie jestem pewny czy niezbędnym jest utworzenie przypadków w formie tekstowej, pomijając już finalne utworzenie z tego dokumentacji aby było to zrobione prosto ale porządnie.

Ja nie dyskutuję z projektem systemu aktorowym czy innym, tylko z rysunkami które niczemu nie służą. Sądzę, ze dobry przekaz tekstowy jest lepszy, niż nie-wiadomo-jakie rysunki

Rozumiem, że jesteś za tym aby bardziej szczegółowe przypadki użycia konstruować w formie PU 1..... aczkolwiek ogólne przypadek użycia obrazujący ogólne działanie systemu chyba zły nie jest. W tym dokumentacja jako finalny efekt