Both sides previous revision
Poprzednia wersja
Nowa wersja
|
Poprzednia wersja
|
pl:miw:miw08_ardcase_uml [2008/06/15 19:45] 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]] |
| |
| |
| |
*[[pl:miw:miw08_ardcase_uml:ard_diagramy|uzyskane diagramy 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 ====== |
W czasie prac związanych z wyszukiwaniem właściwych systemów uzgodniono, że projekt będzie dotyczył | W czasie prac związanych z wyszukiwaniem właściwych systemów uzgodniono, że projekt będzie dotyczył |
systemu rejestacji studentów na seminaria. | systemu rejestacji studentów na seminaria. |
| |
| |
| |
| |
| |
| |
| |
==== 2. Wykonanie projektu i wnioski ==== | ==== 2. Wykonanie projektu i wnioski ==== |
| |
Naczelnym zadaniem w projekcie było uzyskanie diagramu ARD wybranego systemu, poprzez przedstawienie sposobu translacji z diagramów UML. Kluczem do rozwiązania problemu było odnalezienie istotnych diagramów UML, istotnych czyli tych 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. | 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: | Wygenerowany diagram w ARD przedstawia kilka istotnych informacji na temat modelowanego systemu: |
1. System rejestracji studentów to tak naprawdę kilka mniejszych systemów, które ze sobą współpracują. | - System rejestracji studentów to tak naprawdę kilka mniejszych systemów, które ze sobą współpracują. |
2. Pierwszy z podsystemów przedstawia relację, że plan studenta oraz historia jego seminariów są w związku z opłatą oraz terminem seminarium | - Pierwszy z podsystemów przedstawia relację, że plan studenta oraz historia jego seminariów są w związku z opłatą oraz terminem seminarium |
3. Drugi z podsystemu 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. | - 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. |
3. Trzeci podsystem przedstawia relację, że potwierdzenie zapisu jest dokonywane przez prowadzącego na podstawie utworzonej przez niego listy studentów. | - 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 ? | 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 ==== | ==== 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]]** | |
| |
===== ===== | ===== ===== |