Temat: jak zacząć z UML

Paweł Koralewski:
Doszedłem do wniosku, że nadszedł mój czas na zaprzyjaźnienie się z UMLem (Lepiej późno niż wcale). Trochę poczytałem, ale mam mętlik. Proszę o odpowiedzi na poniższe pytania, które mi powinny ułatwić start. Dodam, że zawodowo zajmuję się tworzeniem stron www, ale bardziej jako programista niż webmajster.

1. Są różne rodzaje diagramów. Który użyć do:
-opisu struktury bazy

nie w UML tylko ERD

-opisu klas (właściwości, metody, dziedziczenie)

diagram klas

-opisu przepływu informacji między klasami

diagram sekwencji

-opisu działań użytkownika i różnych akcji w zależności od jakichś zdarzeń

diagram sterowania interakcją

-opisu wymagań klienta

Use Case (a w ogóle to jak definiujesz "wymagania klienta"?)

2. W jaki sposób podejść do modelowania projektu, od czego zacząć?

tema rzeka :), są różne metodyki

3. Czy do projektowania interfejsu użytkownika posiłkować się jakimś zewnętrznym narzędziem?

UML sam tego nie wspiera ale VP na narzędzie wbudowane (ma w pakiecie Agilian, nie wiem jak UML)

Jako program do tworzenia diagramów wybrałem Visual Paradigm for UML. Do nauki korzystam z wersji Community-Edition. Czy wersja UML modeler wystarczy mi później do pracy?

Sam musisz ocenić tu np.:
http://www.visual-paradigm.com/product/vpsuite/compare...

Temat: jak zacząć z UML

Paweł Koralewski:

2. W jaki sposób podejść do modelowania projektu, od czego zacząć?

tema rzeka :), są różne metodyki

Zdaję sobie sprawę, jednak chciałbym tę rzekę przepłynąć. Jakieś wskazówki na początek? Czy może zacznę od czegoś konkretnego, czyli opiszę słownie i do tego przypadku podasz mi wskazówki?

chyba najlepsza kolejność to:
1. nauka analizy i projektowania obiektowego
2. programowanie obiektowe (w zasadzie implementacja projektów obiektowych)

co do metodyk to ostatnio bardzo popularny jest ICONIX, proponuje także poznanie podstawowego wzorca projektowego MVC, innych obiektowych wzorców projektowych, studiowanie kodu takich rzeczy jak np. wordpress.

aha, proponuje nigdy nie zaczynać od bazy danych, to powinna być ostatnia rzecz...

P.S.
w kwestii ekranów: kolega do dzisiaj używa papieru i ołówka :) Jarek Żeliński edytował(a) ten post dnia 10.02.11 o godzinie 12:30

Temat: jak zacząć z UML

Paweł Koralewski:
Zdaję sobie sprawę, że korzystając z narzędzi różnych firm, zmiany będę musiał nanosić dwukrotnie.

weź pod uwagę, że model danych raczej projektuje się już po wykonaniu modelu obiektowego, w systemach projektowanych obiektowo nie są to skomplikowane modele (bardzo często wzorzec active record) wiec nie będzie potrzeby tworzenia skomplikowanego modeli ERD i zmian w dokumentacji obiektowej, dopiero zaawansowane projekty ORM mogą tego wymagać ...

Temat: jak zacząć z UML

tu troszke o metodach
http://msdn.microsoft.com/pl-PL/library/dd409423(v=VS....Jarek Żeliński edytował(a) ten post dnia 10.02.11 o godzinie 16:08

Temat: jak zacząć z UML

Grzegorz Kukawski:
Uzupełnię tylko, że bazę danych, skoro wybrałeś UML, możesz obsłużyć za pomocą diagramu klas.

Co do 2. ja preferuję podejście "od biznesu do systemu" czyli np.:
1. Ogólna wizja systemu (główne wymagania na system, jakie problemy rozwiązywać, jak ma być finansowany, jacy są kluczowi interesariusze).
2. Model dziedziny (aby lepiej poznać byty występujące w modelowanej rzeczywistości)
3. Procesy biznesowe - czyli zrozumienie działań biznesowych, które chcemy wspomóc za pomocą systemu.
4. Przypadki użycia - czyli punkt styku świata zewnętrznego z systemem (również styp procesów biznesowych z systemem, bo przecież to w ramach nich system będzie wykorzystywany)
5. Diagram klas - struktura systemu

Dalej już jest mniej oczywiste, ale na robry początek chyba wystarczy

ach te dyskusje i polemiki :), ale od tyłu: w kwestii metody jak najbardziej polecam opisane podejście od biznesu do implementacji, sam takie stosuje ale:
- procesy w UML to wyzwanie dla czytających i ja preferuję tu jednak BPMN (czyli nie UML), jeżeli już UML to diagram czynności z odpowiednim profilem
- osobiście jestem wrogiem modelowania danych diagramem klas bo po pierwsze są to klasy a nie encje a po drugie semantyka ERD i UML/Diagram klas jednak się różni i modelując dane w UML albo naginamy syntaktykę UML albo upraszczamy model danych, lepiej już do modelu dziedziny dodać nieformalny diagram mapowania ORM co będzie zresztą bliższe prawdy...

ale to "szczegóły", co do zasady zgadzam się z przedmówca :)

jak widzisz nie ma jedynie słusznego podejścia są mniej czy bardziej równoważne metody i coś trzeba wybrać :), gdybyś miał obstawac przy UML to sugeruję diagram czynności plus dobry profil a dane jednak "czysty" UML + mapowanie ORM (zwracam uwagę, że w UML nie istnieje pojęcie kluczy do tabel, nie ma pojęcia tabela, widok, itp...)