Różnice między wybraną wersją a wersją aktualną.
| Both sides previous revision Poprzednia wersja Nowa wersja | Poprzednia wersja | ||
|
pl:miw:miw08_xttplusapps [2008/09/17 10:19] miw |
pl:miw:miw08_xttplusapps [2019/06/27 15:50] (aktualna) |
||
|---|---|---|---|
| Linia 1: | Linia 1: | ||
| ====== Opis ====== | ====== Opis ====== | ||
| + | __**Projekt zakończony**__ | ||
| - | R: Łukasz Dziewanowski (4AR) <dziewano@student.agh.edu.pl> | + | **Łukasz Dziewanowski** (4AR) <dziewano@student.agh.edu.pl> |
| Try to apply, refine xtt+ features, design real-life SE cases using xtt+ | Try to apply, refine xtt+ features, design real-life SE cases using xtt+ | ||
| Linia 9: | Linia 10: | ||
| case: webserver | case: webserver | ||
| - | + | [[pl:miw:miw08_xttplusapps:spotkania]] | |
| - | ====== Spotkania ====== | + | |
| - | + | ||
| - | ===== 08.03.04 ===== | + | |
| - | * przykłady: webserver, pralka | + | |
| - | * wiedza zapisana regułowo | + | |
| - | + | ||
| - | ===== 08.03.18 ===== | + | |
| - | + | ||
| - | ===== 08.04.08 ===== | + | |
| - | * użycie [[hekate:hqed]] do modelowania | + | |
| - | * wybrać przykłady z [[pl:miw:miw08_ardcase_cs#control_system_models]] [[pl:miw:miw08_ardcase_uml#linki_do_uml_i_mvc]] | + | |
| ====== Opis projektu ====== | ====== Opis projektu ====== | ||
| Linia 32: | Linia 22: | ||
| ====== Opis przykładów ====== | ====== Opis przykładów ====== | ||
| ==== Webserwer ==== | ==== Webserwer ==== | ||
| - | Jednym z najbardziej popularnych i używanych na szeroką skalę serwerów WWW jest Apache – w chwili obecnej wersja 2.2.9, wersja 1.3 jest opisana tutaj . Jest to serwer z którym praktycznie każdy kto miał kontakt z Internetem, się spotkał – możliwe, że nawet o tym nie wiedząc. Ma on budowę modułową dzięki czemu łatwo można go rozbudować. Ale dość wstępu – wybrałem taki przykład gdyż pokazuje on przejrzyście grupę obiektów w którym każdy ma określone z góry obowiązki. Uproszczoną budowę przedstawię na diagramie UML: | + | Jednym z najbardziej popularnych i używanych na szeroką skalę serwerów WWW jest Apache – w chwili obecnej wersja 2.2.9, wersja 1.3 jest opisana tutaj [1]. Jest to serwer z którym praktycznie każdy kto miał kontakt z Internetem, się spotkał – możliwe, że nawet o tym nie wiedząc. Ma on budowę modułową dzięki czemu łatwo można go rozbudować. Ale dość wstępu – wybrałem taki przykład gdyż pokazuje on przejrzyście grupę obiektów w którym każdy ma określone z góry obowiązki. Uproszczoną budowę przedstawię na diagramie UML: |
| {{:pl:miw:miw08_xttplusapps:serwer.png|Rysunek 1: Diagram klas serwera Apache}} | {{:pl:miw:miw08_xttplusapps:serwer.png|Rysunek 1: Diagram klas serwera Apache}} | ||
| Linia 50: | Linia 40: | ||
| # Kolejne wersje plików nie nadpisują poprzednich, lecz rozszerzają je poprzez zapisanie zmian jakie nastąpiły w pliku i kolejnego numeru wersji – umożliwia to powrót do wcześniejszych wersji plików. | # Kolejne wersje plików nie nadpisują poprzednich, lecz rozszerzają je poprzez zapisanie zmian jakie nastąpiły w pliku i kolejnego numeru wersji – umożliwia to powrót do wcześniejszych wersji plików. | ||
| - | Świetne wprowadzenie możemy przeczytać w książce , jak również ogólne reguły działania systemu kontroli wersji, ponadto porównanie możliwości z wciąż popularnym CVS. | + | Świetne wprowadzenie możemy przeczytać w książce [2], jak również ogólne reguły działania systemu kontroli wersji, ponadto porównanie możliwości z wciąż popularnym CVS. |
| Pierwszym przykładem był serwer Apache – system Subversion także możemy zakwalifikować do aplikacji klient - serwer, jest to jednak tak wyspecjalizowane narzędzie, że na pierwszy rzut oka trudno zauważyć podobieństwa. Ciekawostką jest, że istnieje moduł do Apache umożliwiający dostęp do repozytorium poprzez właśnie ten serwer. W przedstawionym opracowaniu skupię się jedynie na cyklu korzystania z Subversion tj. założenia kopii roboczej, aktualizowaniu jej, zapisywaniu zmian w repozytorium i rozwiązywaniu konfliktów. Schemat tych działań obrazuje diagram: | Pierwszym przykładem był serwer Apache – system Subversion także możemy zakwalifikować do aplikacji klient - serwer, jest to jednak tak wyspecjalizowane narzędzie, że na pierwszy rzut oka trudno zauważyć podobieństwa. Ciekawostką jest, że istnieje moduł do Apache umożliwiający dostęp do repozytorium poprzez właśnie ten serwer. W przedstawionym opracowaniu skupię się jedynie na cyklu korzystania z Subversion tj. założenia kopii roboczej, aktualizowaniu jej, zapisywaniu zmian w repozytorium i rozwiązywaniu konfliktów. Schemat tych działań obrazuje diagram: | ||
| Linia 60: | Linia 50: | ||
| {{:pl:miw:miw08_xttplusapps:serwer_xtt.png|Rysunek 4: Schemat XTT+}} | {{:pl:miw:miw08_xttplusapps:serwer_xtt.png|Rysunek 4: Schemat XTT+}} | ||
| + | {{:pl:miw:miw08_xttplusapps:webserwer.xttml|Schemat XTTML}} | ||
| + | |||
| + | **connected** ∈ {true, false} | ||
| + | |||
| + | **answer** ∈ {'none', 'normal', 'error', 'disconnect'} | ||
| + | |||
| + | **request** ∈ {'*.html', '*.php', '*.py', 'connect', 'disconnect'} | ||
| + | |||
| + | **handler_id** ∈ {0, 1, 2, -1, -2} | ||
| + | |||
| + | |||
| + | |||
| ==== Subversion ==== | ==== Subversion ==== | ||
| - | {{:pl:miw:miw08_xttplusapps:subversion_xtt.png|Rysunek 5: Schemat XTT+}} | + | {{:pl:miw:miw08_xttplusapps:subversion_xtt.png|Rysunek 5: Schemat XTT}} |
| + | {{:pl:miw:miw08_xttplusapps:subversion.xttml|Schemat XTTML}} | ||
| + | |||
| + | **request** ∈ {'Checkout', 'Update' } | ||
| + | |||
| + | **conflicts** ∈ {true, false} | ||
| + | |||
| + | **answer** ∈ {'ok', 'resolve'} | ||
| + | |||
| + | **action** ∈ {'work', 'resolve'} | ||
| ====== Problemy i wnioski ====== | ====== Problemy i wnioski ====== | ||
| - | Okazuje się, że problemy Knowlege Engineering i Software Engineering pojawiają się już w trakcie próby ujednolicenia zapisu modelu. Podczas gdy dla SE potrafimy wskazać szereg technik, metod i narzędzi pomocnych przy tworzeniu modelu, w przypadku KE jesteśmy bardzo skąpo wyposażeni w te narzędzia. Ponadto okazało się wyjątkowo trudne przejście z modelowania w UML – niejako naturalnego języka SE, do postaci zapisu reguł wykorzystywanych przez KE. Trudności te zostały opisane m.in. w publikacjach ,. Podczas gdy model zapisany w XTT+ odpowiada w całości zapisowi w Prologu (w chwili obecnej jest to chyba najlepszy język KE) i na odwrót, z zapisanego programu w Prologu możemy odtworzyć model XTT+ - UML nie daje nam takiego komfortu. Model UML zawiera wiele niedomówień, nic nam nie mówi o przebiegu procesu modelowania, potrzeba wiele różnorodnych diagramów aby w pełni omówić daną funkcjonalność. Z drugiej strony w UML opieramy się o naszą intuicję tworząc tak naturalne dla człowieka obiekty i powiązania między nimi – co daje dużą swobodę projektantowi. XTT+ brakuje pojęcia obiektu jako takiego – obiektem jest pewien zbiór atrybutów i opierających się na nich reguł. Nie pozwala to na swobodne przechodzenie z projektowania w sposób obiektowy, na sposób zapisu reguł – nie pomaga w tym również skąpy zasób informacji zawarty w diagramach UML. | + | Okazuje się, że problemy Knowlege Engineering i Software Engineering pojawiają się już w trakcie próby ujednolicenia zapisu modelu. Podczas gdy dla SE potrafimy wskazać szereg technik, metod i narzędzi pomocnych przy tworzeniu modelu, w przypadku KE jesteśmy bardzo skąpo wyposażeni w te narzędzia. Ponadto okazało się wyjątkowo trudne przejście z modelowania w UML – niejako naturalnego języka SE, do postaci zapisu reguł wykorzystywanych przez KE. Trudności te zostały opisane m.in. w publikacjach [3],[4]. Podczas gdy model zapisany w XTT+ odpowiada w całości zapisowi w Prologu (w chwili obecnej jest to chyba najlepszy język KE) i na odwrót, z zapisanego programu w Prologu możemy odtworzyć model XTT+ - UML nie daje nam takiego komfortu. Model UML zawiera wiele niedomówień, nic nam nie mówi o przebiegu procesu modelowania, potrzeba wiele różnorodnych diagramów aby w pełni omówić daną funkcjonalność. Z drugiej strony w UML opieramy się o naszą intuicję tworząc tak naturalne dla człowieka obiekty i powiązania między nimi – co daje dużą swobodę projektantowi. XTT+ brakuje pojęcia obiektu jako takiego – obiektem jest pewien zbiór atrybutów i opierających się na nich reguł. Nie pozwala to na swobodne przechodzenie z projektowania w sposób obiektowy, na sposób zapisu reguł – nie pomaga w tym również skąpy zasób informacji zawarty w diagramach UML. |
| Podsumowując, tak jak pojęcia SE i KE oznaczają całkowicie różne podejścia do rozwiązywania problemów przez komputery, tak i nie ma prostego sposobu na przejście z jednej metody do drugiej. Miejmy nadzieję, że podobnie jak w dziedzinie SE nastąpił ogromny rozwój i postęp, tak KE będzie niedługo obfitowało w dogodne narzędzia, metody i techniki. | Podsumowując, tak jak pojęcia SE i KE oznaczają całkowicie różne podejścia do rozwiązywania problemów przez komputery, tak i nie ma prostego sposobu na przejście z jednej metody do drugiej. Miejmy nadzieję, że podobnie jak w dziedzinie SE nastąpił ogromny rozwój i postęp, tak KE będzie niedługo obfitowało w dogodne narzędzia, metody i techniki. | ||
| + | |||
| + | ====== Bibliografia ====== | ||
| + | - Engelschall, Ralf S., Apache Desktop Reference, 2001 | ||
| + | - Collins-Sussman, Ben; Fitzpatrick, Brian W.; Pilato, C. Michael, Version Control with Subversion: For Subversion 1.4, 2002 | ||
| + | - Nalepa, Grzegorz J.; Wojnicki, Igor, Using UML for Knowledge Engineering - A Critical Overview, 2007 | ||
| + | - Nalepa, Grzegorz J.; Kluza, Krzysztof, UML Representation Proposal for XTT Rule Design Method, | ||
| ====== Materiały ====== | ====== Materiały ====== | ||
| - [[.:miw08_xttplusapps:notatki|Notatki]] | - [[.:miw08_xttplusapps:notatki|Notatki]] | ||
| - [[.:miw08_xttplusapps:linki|Linki]] | - [[.:miw08_xttplusapps:linki|Linki]] | ||
| + | - [[.:miw08_xttplusapps:pliki|Pliki]] | ||
| - xtt, GREP (enase,inap) FIXME | - xtt, GREP (enase,inap) FIXME | ||
| * [[:hekate:bib:hekate_bibliography]] | * [[:hekate:bib:hekate_bibliography]] | ||
