Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jarek Żeliński:

wazna dla mnie konkluzja jest na pewno to, że modele UMl to dokuemntacja a kod programu do implementacja, dokuemntacja ma mówić o co chodzi mino tego, ze konkretny język programowania może miec pewne ograniczenia (np. brak wielodziedziczenia) itp...

Dokładnie tak. Model to nie jest rzeczywistość tylko jej abstrakcyjna projekcja. Warto jednak zwrócić uwagę na to, że modele też bywają mniej lub bardziej szczegółowe. Te bardziej ogólne mogą abstrahować od technologii. Te szczegółowe muszą być już z technologią zgodne. Albo inaczej im model bardziej szczegółowy tym silniej musi uwzględniać technologie.

byc może kłopot w tym, że programista nie "implementuje" klas abstrakcyjnych gdyz służa one jedynie do pzrekazania pewnych informacji, więc możliwe że może "nie lubić i nie rozumieć" tych klas... jeżeli nie ma ich w swoim narzędziu czyli kompilatorze...[edited]Jarek Żeliński edytował(a) ten post dnia

Gwarantuję panu, że będąc programistą implementuję całe mnóstwo klas abstrakcyjnych i interfejsów. Powiem więcej, na etapie prac wykonawczych, stworzenie interfejsów daje spore możliwości jeżeli chodzi o zarządzanie projektem. Na etapie modelowania, im jestem dalej od implementacji tym więcej definicji interfejsów w modelu a mniej konkretnych klas.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Artur Kęska:
Na etapie modelowania, im jestem dalej od implementacji tym więcej definicji interfejsów w modelu a mniej konkretnych klas.

to tak jak u mnie :), zamiast rozbierac na drobne zbedne na początkowym etapie szczegóły wrzucam interfejs lub ogólną klase abstrakcyjna i ta metoda mozna zbudować model pokaźnego systemu ogarniajac szybko jego całośc..;)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Mateusz Kurleto:
Zignorujmy na chwilę wysublimowane słownictwo, bo z racji godziny nie chce mi się go używać. Powiedzmy sobie wprost. Kiedyś nie używało się tak powszechnie interfejsów i interfejsy były na styku sprzętu i użytkownika. Klawiatura była interfejsem komputera, potem były interfejsy systemów - system był bazodanowy i miał dwa interfejsy - desktopowy i webowy. A potem mądrzy ludzie (głównie od zabezpieczeń) stwierdzili, że z każdej klasy można wydzielić część publiczną, zrobić ją osobną klasą i tą klasę nazwali interfejsem. A zatem interfejs JEST klasą. UML to dla mnie narzędzie a nie przedmiot studiów nad interpunkcją w specyfikacji. Więc nawet nie sięgam do niej by sypać cytatami. Interfejs to klasa. Jak ją zamodelujesz - Twoja sprawa. Jak dla mnie możesz w ogóle nie korzystać z predefiniowanych rozwiązań języka i zrobić osobną klasę połączoną z klasą podstawową. Będzie równie użyteczne. Możesz ją nawet za zaleceniami ustawy o języku polskim iblabla nazwać międzymordzie.

Ogólnie się zgadza.
Interfejsy są specyficzną i integralną częścią wielu języków programowania i na diagramie UML niewiele się różnią od klas. Problem w tym że interfejs jest bardzo istotny z punktu widzenia zarządzania stykiem między bibliotecznym i zapewnienia ukrycia implementacji/hermetyzacji i jest to wyraźnie widoczne na diagramie komponentów UML.

Dodam, że w takim C++ nie istniał "interface", ale używało się ideii interfejsów jako "pure virtual abstract base class", właśnie po to aby zapewnić odpowiednią i trwałą sygnaturę binarną tego styku między bibliotecznego i zapewnić hermetyzację kodu.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Witam, jestem nowy na tym forum więc pozdrawiam wszystkich:)
Piszę pracę inżynierską na temat systemu weryfikowania wiedzy studentów. Proszę o pomoc odnośnie diagramu przypadku użycia. Mój diagram jest napewno nie najlepszy jeśli nie cały zły.
co mnie interesuje:
- w poprzednich postach było o tym że stosowanie "extend" i "include" w nadmiernych ilościach nie jest dobrą prakytką, u mnie tych związków jest wiele jednak czy można ten diagram jakoś "zwinąć"?
3 główne przypadki zarządzania mają wiele rozszerzeń - czy te rozszerzenia powinny być? Jeśli nie to nie wiem jak ma wyglądać wtedy scenariusz dla tych wielkich przypadków. Jeśli mogą zostać to z drugiej strony ciężko mi napisać jakiś scenariusz dla np "uruchomienie testu". Bo czy jeśli scenariusz ma 1-2 kroki to jest to normalne?

Kolejna sprawa - czy powinienem ten diagram podzielić na części tzn pakiety? Widać na nim co najmniej 3 pakiety pochodzące od przypadków zarządzania (nie wiem czy to co student robi ma być jakimś pakietem).

Informuję, że nie jestem dobry w UML więc proszę o wyrozumiałość i z góry dziękuję za pomoc!!!


Marcin Gościniak edytował(a) ten post dnia 16.10.09 o godzinie 16:36

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Według mnie w Twoim modelu można oddzielnie rozpatrywać dwa zagadnienia. Pierwszym jest uwierzytelnianie, a drugim operacje CRUD.

W ramach wątku http://www.goldenline.pl/forum/uml/1182290 była omawiana kwestia modelowania uprawnień. Dodatkowo w książce "Stosowanie przypadków użycia" G. Schneider, J. P. Winters można znaleźć opis czterech sposobów dokumentowania logowania:
1. logowanie zawiera inne przypadki użycia (Twoje rozwiązanie)
2. inne przypadki użycia zawierają logowanie
3. inne przypadki użycia rozszerzają logowanie
4. logowanie jest niezależne, a inne przypadki mają warunek początkowy
Autor poleca rozwiązanie 4 i mi również wydaje się najbardziej czytelne i elastyczne.

Jeśli chodzi o dokumentowanie operacji CRUD mamy dwa podejścia (ten sam autor):
1. oddzielne przypadki użycia dla każdego rodzaju dostępu do danych
2. jeden przypadek użycia dla typu danych obejmujący wszystkie funkcje CRUD (wiele scenariuszy alternatywnych)

Przypadek 2 to Twój "Zarządzanie...", przypadek 1 to PU w relacji <extend>.
Myślę, że możesz zostać przy podejściu 1. Możesz stworzyć oddzielne PU dla każdego rodzaju operacji, a dla każdego typu danych stworzyć oddzielny diagram PU.

Np. Mamy diagram opisujący zarządzanie użytkownikami, a na nim PU:
Edycja kont, blokowanie kont itp. Kolejny diagram opisujący zarządzanie testami i na nim PU: Edycja testu, usuwanie testu i tak dalej :)Arkadiusz Wrzosk edytował(a) ten post dnia 16.10.09 o godzinie 19:03

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Miło, że na tym forum można przeczytać odpowiedzi, które ludziom coś pomagają:). Dziękuję bardzo za uwagi
Nasuwają mi się kolejne pytanie co do Pana odpowiedzi:
- jak się zaznacza (czy jako notatka, czy jakaś forma na diagramie) warunek początkowy co do tego logowanie bo faktycznie te podejście uczyni diagramy czytelniejszymi
- w dodatku diagram pakietów będzie zawierał u mnie 3 pakiety zarządzanie testami,użytkownikami i raportami. Gdzie mam "wrzucić" przypadki od aktora student?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Zwróciłbym uwagę, że diagram przypadków (UC) użycia nigdy nie zastąpi diagramy klas. UC to TYLKO funkcjonalności z perspektywy użytkownika i nic ponad to.
Diagram zaś zawiera elementy scenariuszy, np.zapisanie testu jest elementem UC Zarządzanie testami, zapisanie użytkownika, odblokowanie konta to prosta czynność w ramach zarządzania kontami, itp. Uwagi kolegi powyżej są słuszne, ja tylko dodam, że moduły programu to raczej diagram klas, UC to tylko "to co może chcieć uzyskać użytkownik" za pomocą programu.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Marcin Gościniak:
Miło, że na tym forum można przeczytać odpowiedzi, które ludziom coś pomagają:). Dziękuję bardzo za uwagi
Nasuwają mi się kolejne pytanie co do Pana odpowiedzi:
- jak się zaznacza (czy jako notatka, czy jakaś forma na diagramie) warunek początkowy co do tego logowanie bo faktycznie te podejście uczyni diagramy czytelniejszymi

Każdy przypadek użycia powinien zostać opisany bardziej szczegółowo. Warunki początkowe to jeden z punktów. Jest to lista warunków, które muszą zostać spełnione przed rozpoczęciem PU.

- w dodatku diagram pakietów będzie zawierał u mnie 3 pakiety zarządzanie testami,użytkownikami i raportami. Gdzie mam "wrzucić" przypadki od aktora student?

Nie chciałbym źle podpowiedzieć ponieważ nie znam szczegółów systemu. Ze względu na to, że pakiet służy do grupowania podobnych znaczeniowo
elementów w dowolnym celu (wg "UML przewodnik użytkownika" G. Booch, J. Rumbaugh, I. Jacobson) wydaje mi się, że PU w relacji ze studentem mogłyby wylądować w pakiecie zarządzania testami. Ewentualnie można dodać kolejny pakiet np. obsługa egzaminu(?) w relacji z pakietem zarządzanie testami.Arkadiusz Wrzosk edytował(a) ten post dnia 16.10.09 o godzinie 19:49

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Arkadiusz Wrzosk:

fakt - będę robił specyfikację przypadków użycia gdzie w formularzu będzie pole o warunkach początkowych;)

Jak Pan Arkadiusz napisał;

"2. jeden przypadek użycia dla typu danych obejmujący wszystkie funkcje CRUD (wiele scenariuszy alternatywnych)"

no właśnie zacząłem pisać scenariusze i np dla przypadku użycia edycja konta mam ;
1. Nauczyciel ustala parametry wyszukiwania
2. Kliknięcie przycisku wyszukaj
3. Wyświetlenie kont spełniających kryteria
4. Wybranie odpowiedniego konta
5. Edycja wybranego profilu
6. Kliknięcie przycisku "zapisz"
7. Informacja zwrotna o powodzeniu akcji

pytania;
- czy tak może wyglądać scenariusz?
- czy powinienem opisywać wszystkie "extend" (jedno z rozszerzeń powyżej), czy jeden przypadek w tym wypadku "zarządzanie użytkownikami"? Jeśli jeden przypadek to jak opisać te wszystkie "extend" jako przebiegi alternatywne? W pewnym kroku powstała by lista opcji do wyboru i tak dalej...
- jak powinien wyglądać od strony gramatycznej scenariusz - tzn. w jakiej formie i w której osobie powinny być wypisywane kolejne kroki?
- przyjmując że scenariusz jest do zaakceptowania czy w scenariuszach powinny znajdować się przebiegi alternatywne dotyczące CRUD? np 7.1 Edycja profilu zakończyła się niepowodzeniem (chodzi o jakiś błąd w bazie), informacja zwrotna,powrót do kroku x.
-jeśli jest dziedziczenie (tak jak u mnie z aktorami), to nauczyciel nie musi już być jakkolwiek połaczony z przypadkiem logowanie?Wystarczy, że jest student tak? Nawiązuję do tego, ponieważ usunę wszystkie związki przypadku użycia "logowanie" i pozostawie go jako niezależny PU.Marcin Gościniak edytował(a) ten post dnia 17.10.09 o godzinie 09:16

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Marcin Gościniak:

- czy powinienem opisywać wszystkie "extend" (jedno z rozszerzeń powyżej), czy jeden przypadek w tym wypadku "zarządzanie użytkownikami"? Jeśli jeden przypadek to jak opisać te wszystkie "extend" jako przebiegi alternatywne? W pewnym kroku powstała by lista opcji do wyboru i tak dalej...

Tak jak pisałem powyżej, operacje CRUD możemy dokumentować w dwojaki sposób:
1. oddzielne przypadki użycia dla każdego rodzaju dostępu do danych
2. jeden przypadek użycia dla typu danych obejmujący wszystkie funkcje CRUD (wiele scenariuszy alternatywnych)

Myślę, że wybrałbym podejście pierwsze. Zrezygnowałbym z dużych przypadków „Zarządzaj...”. Stworzyłbym oddzielny diagram dla każdego typu danych. Przykładowo dla zarządzania użytkownikami utworzyłbym diagram na którym znajdowały by się PU:
- Edytuj konto
- Blokuj konto
- …itd. (przypadki które łączysz teraz z PU „Zarządzaj użytkownikami” relacją rozszerzenia <extend>)

Jeżeli chciałbyś zostać przy podejściu nr 2 to usunąłbym z diagramu wszystkie PU rozszerzające „Zarządzaj...”. Scenariusze usuniętych PU opisałbym jako alternatywne przebiegi PU „Zarządzaj ...”.
Przykładowo dla „Zarządzaj testami”:
1. Przepływ podstawowy: Edytuj test
2. Przepływy alternatywne: Utwórz nowy test, usuń test itd.

- jak powinien wyglądać od strony gramatycznej scenariusz - tzn. w jakiej formie i w której osobie powinny być wypisywane kolejne kroki?

Nazwę PU możesz podawać w formie krótkiego wyrażenia z czasownikiem w trybie rozkazującym na początku (np. Edytuj, Blokuj), określającego pewną czynność pochodzącą ze słownictwa modelowanego systemu.
Przebieg zdarzeń (kroki scenariusza) to ciąg zdań oznajmujących opisujących kolejne kroki PU. W zależności od odbiorcy może być mniej bądź bardziej formalny. Warto zaznaczyć kto panuje nad akcją tzn. „System wyszukuje ...”, „Użytkownik wprowadza...” itp.

- przyjmując że scenariusz jest do zaakceptowania czy w scenariuszach powinny znajdować się przebiegi alternatywne dotyczące CRUD? np 7.1 Edycja profilu zakończyła się niepowodzeniem (chodzi o jakiś błąd w bazie), informacja zwrotna,powrót do kroku x.

Alternatywne ciągi zdarzeń służą właśnie do opisu innych przebiegów niż podstawowy. Wykorzystuje się je w sytuacji, gdy podczas wykonywania kroków scenariusza użytkownik ma możliwość wyboru lub np. wystąpił błąd.

-jeśli jest dziedziczenie (tak jak u mnie z aktorami), to nauczyciel nie musi już być jakkolwiek połaczony z przypadkiem logowanie?Wystarczy, że jest student tak? Nawiązuję do tego, ponieważ usunę wszystkie związki przypadku użycia "logowanie" i pozostawie go jako niezależny PU.

Związek dziedziczenia na diagramach PU oznacza, że jeden z aktorów odgrywa wszystkie role drugiego aktora. Idąc dalej, jeśli aktor „Nauczyciel” dziedziczy po aktorze „Student”, to tak jakby „Nauczyciel” był w relacji z wszystkimi PU, z którymi jest „Student” ;)

- czy tak może wyglądać scenariusz?

Myślę, że po naniesieniu poprawek związanych z tym, kto wykonuje krok, scenariusz będzie ok ;) Przykładowo: Nauczyciel może wyszukać konta na podstawie wybranych kryteriów, System wyświetla konta spełniające kryteria... itd. ;) Z drobnych uwag, moim zdaniem specyfikacja wymagań funkcjonalnych powinna być oderwana od specyfikacji interfejsu. Dlatego usunąłbym element interfejsu jakim jest „przycisk”, w końcu może to być np. odnośnik ;) Jednocześnie myślę, że nie jest to błąd ;)
Najważniejsze, żeby osoba czytająca specyfikację zrozumiała podstawowe wymagania dotyczące systemu :)Arkadiusz Wrzosk edytował(a) ten post dnia 17.10.09 o godzinie 14:56

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jak Pan napisał:

"Przebieg zdarzeń (kroki scenariusza) to ciąg zdań oznajmujących opisujących kolejne kroki PU. W zależności od odbiorcy może być mniej bądź bardziej formalny. Warto zaznaczyć kto panuje nad akcją tzn. „System wyszukuje ...”, „Użytkownik wprowadza...” itp."

Mam pytanie co do powyższego - warto kontrolować kto panuje nad akcją, jednak czy wtedy nie należy dodać aktora "system"? Jeśli w scenariuszu będę używał tego wyrażenia to chyba powinien być (gdzie?) taki aktor na diagramie?
Wszystkie Pana rady rozjaśniają mi wątpliwości bardzo bardzo dziękuję.

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Marcin Gościniak:

Mam pytanie co do powyższego - warto kontrolować kto panuje nad akcją, jednak czy wtedy nie należy dodać aktora "system"? Jeśli w scenariuszu będę używał tego wyrażenia to chyba powinien być (gdzie?) taki aktor na diagramie?

Aktor reprezentuje spójny zbiór ról odgrywanych przez użytkownika przypadku użycia. Aktor wchodzi w interakcję z systemem. Ma cel względem systemu. Użytkownikiem może być człowiek, urządzenie lub inny system. Aktorzy nie są częścią systemu.

Myślę, że jeszcze jedno zagadnienie, które warto poruszyć. Są to PU uruchamiane przez upływ czasu (np. PU odpowiedzialny za wysłanie katalogu 1-go każdego miesiąca). G. Schneider, J. P. Winters w "Stosowanie przypadków użycia" opisują dwie metody:
1. PU sam się uruchamia, a aktorem który komunikuje się z systemem jest ten, który jest zainteresowany generowanymi wynikami
2. Możemy potraktować czas jako aktora, który inicjuje PU (np. aktor Koniec miesiąca).
Skłaniam się ku podejściu 1.Arkadiusz Wrzosk edytował(a) ten post dnia 17.10.09 o godzinie 19:42

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Tworzę dokument specyfikacji wymagań:
pytanie:
- czy mogę utworzyć w takim dokumencie zarówno tabelarycznie zestawione wymagania funkcjonalne (typ wymagania,opis,uzasadnienie,kryterium akceptacji itd..)
jak i specyfikację przypadków użycia? Czy w takim wypadku pewne informację nie będą się powtarzały?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Marcin Gościniak:
Tworzę dokument specyfikacji wymagań:
pytanie:
- czy mogę utworzyć w takim dokumencie zarówno tabelarycznie zestawione wymagania funkcjonalne (typ wymagania,opis,uzasadnienie,kryterium akceptacji itd..)
jak i specyfikację przypadków użycia? Czy w takim wypadku pewne informację nie będą się powtarzały?

obawiam się, że przypadki użycia to wymagania funkcjonalne...

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

pytanie moje powstało jak zobaczyłem ten szablon:
Szablon

w punkcie 2.4 są krótkie opisy przypadków użycia
w punkcie 5 są tabelaryczne opisy wymagań funkcjonalnych

- czy w takim dokumencie i jeśli tak to gdzie mają się znajdować scenariusze PU?
- scenariusze to jeden z elementów specyfikacji przypadków użycia czy w związku z tym można byłoby je zamieścić jako kolejny wiersz w tabeli z pkt 5? Chodzi mi o logikę takiego dokumentuMarcin Gościniak edytował(a) ten post dnia 17.10.09 o godzinie 23:30

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Marcin Gościniak:
pytanie moje powstało jak zobaczyłem ten szablon:
Szablon

w punkcie 2.4 są krótkie opisy przypadków użycia
w punkcie 5 są tabelaryczne opisy wymagań funkcjonalnych

- czy w takim dokumencie i jeśli tak to gdzie mają się znajdować scenariusze PU?
- scenariusze to jeden z elementów specyfikacji przypadków użycia czy w związku z tym można byłoby je zamieścić jako kolejny wiersz w tabeli z pkt 5? Chodzi mi o logikę takiego dokumentuMarcin Gościniak edytował(a) ten post dnia 17.10.09 o godzinie 23:30

Dziwny szablon... musisz się go trzymać? Dużo korzystniej jest zrobić to tak jak proponuje Jarek.
Chyba, że to jakiś dokument odzwierciedlający plan pracy semestralnej, który oddajesz etapami w ciągu semestru - wtedy najpierw pokazujesz diagram i krótkie opisy, a potem wymagania funkcjonane - czyli szczegółowy opis UC...

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

chciałbym zrobić jakiś dokument specyfikacji wymagań, czy polecacie jakiś szablon?

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Moim zdaniem poniższy szablon jest wystarczający na Twoje potrzeby :)

1. Wstęp
2. Przegląd modelu przypadków użycia - diagram, ogólny opis modelu, dla każdego PU: nazwa, krótki opis, lista aktorów (w postaci tabelarycznej)
3. Przegląd aktorów - nazwa, opis aktora
4. Wymagania funkcjonalne (szczegółowy opis PU)
Dla każdego PU:
- krótki opis
- przebieg zdarzeń (podstawowy, alternatywne)
- warunki wstępne
- warunki końcowe
5. Wymagania niefunkcjonalne: niezawodność, efektywność itd.
6. Ograniczenia projektowe
7. Słownik pojęćArkadiusz Wrzosk edytował(a) ten post dnia 18.10.09 o godzinie 22:53

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

7. Słownik pojęć

osobiście praktykuje słownik na początku ;) ale to takie tam :) ogólnie szablon Arka na Twoje potrzeby na moje oko jest wystarczający...

Ważne jest jednak czego oczekuje zaliczający, w przyszłości najważniejsze jest oczekiwanie odbiorcy dokumentacji ... nie powinno ono jednak obniżyć jakości i poziomu dokumentu :)

Temat: UMLowa ośla łączka ;) czyli komentujemy ale nie czepiamy się

Jeśli warunki wstępne to np. "użytkownik jest zalogowany", to jak rozumieć "Warunki końcowe"?Marcin Gościniak edytował(a) ten post dnia 19.10.09 o godzinie 16:50