Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
|
pl:miw:miw08_ardcase_uml [2008/06/15 13:27] miw |
pl:miw:miw08_ardcase_uml [2019/06/27 15:50] (aktualna) |
====== Opis ====== | ====== Opis ====== |
| __**Projekt zakończony**__ |
| |
Artur Poniedziałek (4AR) <arturponiedzialek@gmail.com> | Artur Poniedziałek (4AR) <arturponiedzialek@gmail.com> |
| |
====== Spotkania ====== | ====== Spotkania ====== |
*[[pl:miw:miw08_ardcase_uml:projekt|przebieg prac nad projektem]] | *[[pl:miw:miw08_ardcase_uml:projekt|przebieg prac nad projektem]] |
| |
| |
| |
| |
| |
| |
| |
| |
====== Projekt ====== | ====== Projekt ====== |
| |
| *[[pl:miw:miw08_ardcase_uml:aktualnewyniki|opracowanie projektu]] |
| *[[pl:miw:miw08_ardcase_uml:ard|rejestracja studentów w ARD]] |
| *[[pl:miw:miw08_ardcase_uml:ard_diagramy|uzyskane diagramy w ARD]] |
| |
| Gotowe przykłady w UML: |
| * {{:pl:miw:miw08_ardcase_uml:borland.zip|:pl:miw:miw08_ardcase_uml:borland.zip}} |
| * {{:pl:miw:miw08_ardcase_uml:kompletny_prosty_system.zip|:pl:miw:miw08_ardcase_uml:kompletny_prosty_system.zip}} |
| * {{:pl:miw:miw08_ardcase_uml:sparx.zip|:pl:miw:miw08_ardcase_uml:sparx.zip}} |
| * {{:pl:miw:miw08_ardcase_uml:sun_java_-_system_udzielania_pozyczek.zip|:pl:miw:miw08_ardcase_uml:sun_java_-_system_udzielania_pozyczek.zip}} |
| * {{:pl:miw:miw08_ardcase_uml:system_seminariow_dla_studentow.zip|:pl:miw:miw08_ardcase_uml:system_seminariow_dla_studentow.zip}} |
| |
====== Sprawozdanie ====== | ====== Sprawozdanie ====== |
| |
| |
| |
| ==== 1. Cel projektu==== |
| Celem projektu było stworzenie diagramu ARD w oparciu o diagramy UML/MVC pewnego systemu. |
| W czasie prac związanych z wyszukiwaniem właściwych systemów uzgodniono, że projekt będzie dotyczył |
| systemu rejestacji studentów na seminaria. |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| ==== 2. Wykonanie projektu i wnioski ==== |
| |
| Naczelnym zadaniem w projekcie było uzyskanie diagramu ARD wybranego systemu, poprzez przedstawienie sposobu translacji diagramów UML. Kluczem do rozwiązania problemu było odnalezienie istotnych diagramów UML, istotnych czyli takich co w pierwszym przybliżeniu pasowałyby do właściwości "prostych" oraz "złożonych" (tzw. atrybuty fizykalne oraz konceptualne) funkcjonujących w terminologi ARD. |
| |
| Można zadać pytanie czy w ogóle istnieje funkcja przejścia (translacji) diagramów UML do ARD ? Na powyższe pytanie nie można tak po prostu odpowiedzieć. Jedno jest natomiast pewne diagramy w UML tworzy się od najbardziej ogólnych (przypadki użycia, diagramy klas dla dziedziny) po bardziej szczegółowe (diagramy klas w analizie, diagramy sekwencji i kooperacji). Nie inaczej jest w przypadku ARD: zaczynamy od pewnych ogólnych pojęć (atrybuty konceptualne) i poprzez ich podział lub zamianę osiągamy na najbardziej szczegółowym poziomie atrybuty fizykalne oraz operacje jakie można na nich wykonać. |
| |
| Temat projektu sugeruje wykorzystanie diagramów behawioralnych UML'a. Jest to sensowne podejście, ale wydaje się, że nie w początkowej fazie projektu. Skoro ARD to zbiór atrybutów i operacji to powinniśmy najpierw ustalić czym się zajmujemy a dopiero potem jak tego używamy. Nasuwa się pomysł, że powinniśmy zacząć od struktury, czyli od diagramów klas w UML'u. |
| |
| Diagramy klas na wczesnym etapie projektu mają specyfikowany zbiór atrybutów i prostych operacji jakie zmieniają stan poszczególnych instancji (obiektów wspomnianych klas). Taki tok myślenia został właśnie przyjęty w projekcie. Na wstępie został wybrany zbiór najbardziej podstawowych właściwości z diagramów klas systemu UML, a następnie zaczynając od atrybutu konceptualnego zaczęto tworzyć system w ARD. |
| |
| Wygenerowany diagram w ARD przedstawia kilka istotnych informacji na temat modelowanego systemu: |
| - System rejestracji studentów to tak naprawdę kilka mniejszych systemów, które ze sobą współpracują. |
| - Pierwszy z podsystemów przedstawia relację, że plan studenta oraz historia jego seminariów są w związku z opłatą oraz terminem seminarium |
| - Drugi z podsystemów przedstawia dwie relacje, że student jest w związku z prowadzącym, a prowadzący musi uwzględniać fakt czy student brał wcześniej udział w seminarium, i czy są np. wolne miejsca aby zapisać studenta. |
| - Trzeci podsystem przedstawia relację, że potwierdzenie zapisu jest dokonywane przez prowadzącego na podstawie utworzonej przez niego listy studentów. |
| |
| W tym momencie pozornie prosty system nieco się skomplikował. W istocie mamy teraz trzy mniejsze podsystemy, które pracują w pewien określony sobie sposób. Nasuwa się pytanie czy te systemy są niezależne ? Czy w ogóle mogą być niezależne skoro wszystkie dotyczą systemu rejestracji studenta ? |
| |
| Te i wiele innych pytań z całą pewnością mogą posłużyć za temat kolejnego projektu. Trzeba przeanalizować co nam daje informacja, że początkowo jeden system stał się nadsystemem w stosunku do nowych trzech systemów. Jak ten fakt dalej wykorzystać ? Czy jest to jedyny sposób realizacji rejestracji studentów ? Czy inne diagramy uml dałyby zbliżony diagram ARD analizowanego systemu ? |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| ==== 3. Napotkane problemy ==== |
| |
| Trzeba powiedzieć na wstępie, że ARD jest stosunkowo słabo udokumentowane a przynajmniej niewłaściwie. Przykład termostatu jest specyficzny i nie objaśnia dobrze składni dla split'a dla atrybutów konceptualnych. Oficjalne dokumenty opisujące ARD jak choćby [[hekate:bib:hekate_bibliography#gjn2008flairs-ardprolog]] w prawdzie podają wiele przykładów split ( podziału ), ale nigdzie nie jest podany jeden kompleksowy przykład opisujący listy jakie trzeba podać jako "argumenty" split'a. Byłoby dobrze przedstawić podział dla przykładowego atrybutu [ a , b , c ], który ma zostać podzielony na inne atrybuty np. [a,b] oraz [c] czy też [c] i [a,b] odpowiednio zależnościami [a,b] -> [c] ( [a,b] zależy od [c]) oraz [c] -> [a,b] ( [c] zależy od [a,b] ). |
| Krótko mówiąc opisać parametry splita: |
| - atrybut do podziału np. [a,b,c,d,e] |
| - lista nowych atrybutów np. [ [a,b] , [c], [d,e] ] |
| - lista list połączeń między nowymi atrybutami np. [ [ [a,b], [c] ], [ [c], [d,e] ] ]. |
| |
| Brak powyższego opisu sprawił, że godziny spędzone nad próbą tworzenia diagramu ARD w systemie Varda przeszły do historii jako "źle wykorzystane". |
| |
| Druga kwestia jest związana z wykorzystaniem środowiska Varda. Na stronie [[hekate:varda|Varda]] w prawdzie rozdzielono przykład użycia Vardy w systemie Unix/Windows, ale nie wyjaśniono choćby co robią komendy: |
| |
| <code> |
| ?- sar('therm-ard.dot'). |
| ?- shi('therm-tph.dot'). |
| ?- gax. |
| ?- sxt('therm-xtt.dot'). |
| </code> |
| |
| Wspomniano tylko, że służą do generowania diagramów w Graphizie nie wyjaśniając, że tworzą one kod rozumiany przez Graphiza, który trzeba "skompilować" w Graphizie aby otrzymać plik bitmapy, png czy jpg. Na temat Graphiza wiadomo tylko, że jest "needed to build visual models". |
| |
| Tych kilka "komend" prologu wywoływanych z Vardy to chyba niepełny potencjał. W zasadzie co robi sar, shi, gax ? Nie napisano choćby jak wywołać helpa w Vardzie (oczywiście można powiedzieć, że doświadczony użytkownik metodą prób i błędów dojdzie to tego). Może warto przedstawić wynik działania helpa w Vardzie na stronie [[hekate:varda|Varda]] ? |
| |
====== Materiały ====== | ====== Materiały ====== |
* [[http://www.pst.informatik.uni-muenchen.de/~kochn/pUML2001-Hen-Koch.pdf|ogólnie o modelowaniu webowym]] | * [[http://www.pst.informatik.uni-muenchen.de/~kochn/pUML2001-Hen-Koch.pdf|ogólnie o modelowaniu webowym]] |
* [[http://services.eng.uts.edu.au/~dbl/archive/2003-Low02b.pdf|rozrzerzenie UMLa o diagramy potrzebne do modelowania MVC]] | * [[http://services.eng.uts.edu.au/~dbl/archive/2003-Low02b.pdf|rozrzerzenie UMLa o diagramy potrzebne do modelowania MVC]] |
| |
| |
| |
| |
| |
**[[http://student.agh.edu.pl/~poniedzi/uml/|Wyniki aktualnych prac]]** | |
| |
===== ===== | ===== ===== |