Różnice

Różnice między wybraną wersją a wersją aktualną.

Odnośnik do tego porównania

Both sides previous revision Poprzednia wersja
Nowa wersja
Poprzednia wersja
pl:miw:miw08_ardcase_cs:winda [2008/03/10 01:05]
miw
pl:miw:miw08_ardcase_cs:winda [2019/06/27 15:50] (aktualna)
Linia 8: Linia 8:
 P2: {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|Very well documented Elevator Model (local copy)}} P2: {{:​pl:​miw:​miw08_ardcase_cs:​download.zip|Very well documented Elevator Model (local copy)}}
  
-P3: [[http://​regulus.ia.agh.edu.pl/gjn-Regulus-WWW/​miw2002/​MIW02-projekty/​MIW02-Winda.pdf|Students MiW Project by J.Sysak, P.Zieliński]] {{:​pl:​miw:​miw08_ardcase_cs:​miw02-winda.pdf|local copy}}+P3: {{:pl:​miw:​miw08_ardcase_cs:​miw02-winda.pdf|Students MiW Project by J.Sysak, P.Zieliński ​<local copy>}} 
 + 
 + 
  
 ==== Uzasadnienie wyboru i porównanie ==== ==== Uzasadnienie wyboru i porównanie ====
 Wybrany przykład - P1 jest bardzo dobrze zamodelowanym i udokumentowanym systemem. Tę cechę posiada również przykład P2, jednak w przypadku przykładu P2 mimo wielu diagramów analiza wydaje się zbyt uboga (m.in. tylko dwa use-case'​y). Za bazowy uznaję przykład P1. Jeśli na etapie projektowania/​prototypowania okaże się, iż w modelu brakuje ważnych z punktu widzenia realizowanego projektu informacji bądź schematów zostaną one zaczerpnięte z przykładu P2. Przykład P3 jako, że nie jest zamodelowany w języku UML może przydać się przy wyodrębnianiu artybutów/​definiowaniu reguł. Wybrany przykład - P1 jest bardzo dobrze zamodelowanym i udokumentowanym systemem. Tę cechę posiada również przykład P2, jednak w przypadku przykładu P2 mimo wielu diagramów analiza wydaje się zbyt uboga (m.in. tylko dwa use-case'​y). Za bazowy uznaję przykład P1. Jeśli na etapie projektowania/​prototypowania okaże się, iż w modelu brakuje ważnych z punktu widzenia realizowanego projektu informacji bądź schematów zostaną one zaczerpnięte z przykładu P2. Przykład P3 jako, że nie jest zamodelowany w języku UML może przydać się przy wyodrębnianiu artybutów/​definiowaniu reguł.
 +Mimo powyższego jednak algorytm ruchu windy, mimo, iż diagramy UML - use-case i aktywności precyzują działanie windy sprowadza się ono jednak do zbioru reguł prezentowanego w P3, dlatego to on zostanie zaimplementowany.
 +Wezwanie windy sprowadzić można do sprawdzenia czy wezwanie jest z nad windy czy z poniżej aktualnej pozycji windy, podobnie wezwania wewnętrzne (z przykładu P3 zostaną usunięte warunki i konkluzje dotyczące przeciążenia windy jako, że modele UML nie specyfikowały takiej funkcjonalności).
  
-==== Próby modelowania ​====+ 
 + 
 + 
 + 
 +===== Description ===== 
 +Przykład zakłada realizacje podstawowych funkcji windy jak przywołanie windy, wybranie piętra docelowego, wskazywanie położenia wewnątrz i na zewnątrz windy, wskazywanie kierunku jazdy, jazde windy między piętrami, wyliczanie na które piętro pojechać. W przeciwieństwie do innych przykładów działanie windy zależy w wielkim stopniu nie tylko od akcji podejmowanych przez pasażerów w danym momencie, ale także od "​pamięci"​ windy (tj. wcześniejszych wezwań), aktualnego jej stanu - aktualnego kierunku jazdy etc. 
 + 
 + 
 + 
 + 
 +===== Conceptualization =====
 Na tym etapie na podstawie modelu następuje próba wyselekcjonowania wejść, wyjść, wyselekcjonowanie atrybutów (fizycznych i ogólnych), próba zamodelowania reguł panujących w systemie przy pomocy atrybutów. Na tym etapie na podstawie modelu następuje próba wyselekcjonowania wejść, wyjść, wyselekcjonowanie atrybutów (fizycznych i ogólnych), próba zamodelowania reguł panujących w systemie przy pomocy atrybutów.
 +
 +
 +==== Vocabulary ====
  
 Wejścia: wezwania windy z zewnątrz, wezwania windy z kabiny ​ Wejścia: wezwania windy z zewnątrz, wezwania windy z kabiny ​
 +
 Wyjścia: określenie kierunku ruchu, oraz piętra na którym się zatrzymać (technicznie wypracowanie sterowania...) ; w pewnym sensie wyjścia to także wskaźniki w windzie i poza nią Wyjścia: określenie kierunku ruchu, oraz piętra na którym się zatrzymać (technicznie wypracowanie sterowania...) ; w pewnym sensie wyjścia to także wskaźniki w windzie i poza nią
  
-**// ToDo Uściślić dokładniej co przyjmujemy za wejście ​wyjście ; kwestii logiki wejścia ​są to tylko wezwania, ​wyjścia to tylko zachowanie ​windy, ​czy uwzględniać wskaźniki etc. Na jakim etapie (potrzebne ​do modelowania przejść) wprowadzić takie rzeczy jak położenie kabiny ​kierunek ruchu czy robić to technicznie ​enkodery etcczy wystarczy koncepcyjnie ​<ogólnie kontrola położenia**+Stany wewnętrzneAktualne położenie, aktualny kierunek ruchu 
 + 
 + 
 + 
 +==== Original Rules ==== 
 +Reguły:  
 + 
 +tabela decyzyjna -> kierunek jazdy  
 + 
 +tabela decyzyjna + aktualne piętro -> stop czy jazda dalej  
 + 
 +przyciski zewnątrz ​wewnątrz -> zmiana ​kontrolerze  
 + 
 +===== Analysis ===== 
 + 
 + 
 + 
 +===== Conceptual design ===== 
 + 
 +Poziom 0: Winda 
 + 
 +Poziom 1: Finalizacja Windy na: Aktualny kierunek windy, Poprzedni kierunek windy, Czy jest żądanie jazdy w gorę z kabiny, Czy jest żądanie jazdy w dół z kabiny, Czy jest żądanie jazdy na aktualne piętro z kabiny, Czy są wezwania ​z wyższych pięter do jazy w góręCzy są wezwania z wyższych pięter do jazdy w dół, Czy są wezwania z niższych pięter do jazdy w górę, Czy są wezwania z niższych pięter do jazdy w dół Czy są wezwania z aktualnego piętra do jazdy w górę, Czy są wezwania z aktualnego piętra do jazdy w dół, Decyzja gdzie jechać 
 + 
 +Poziom 2: Split: Aktualny kierunek ​windy -> Decyzja gdzie jechaćPoprzedni kierunek windy -> Decyzja gdzie jechać, Czy jest żądanie jazdy w gorę z kabiny -> Decyzja gdzie jechać, Czy jest żądanie jazdy w dół z kabiny -> Decyzja gdzie jechać, Czy jest żądanie jazdy na aktualne piętro z kabiny -> Decyzja gdzie jechać, Czy są wezwania z wyższych pięter ​do jazy w górę -> Decyzja gdzie jechać, Czy są wezwania z wyższych pięter do jazdy w dół -> Decyzja gdzie jechać, Czy są wezwania z niższych pięter do jazdy w górę -> Decyzja gdzie jechać, Czy są wezwania z niższych pięter do jazdy w dół -> Decyzja gdzie jechać, Czy są wezwania z aktualnego piętra do jazdy w górę -> Decyzja gdzie jechać, Czy są wezwania z aktualnego piętra do jazdy w dół -> Decyzja gdzie jechać  
 + 
 +Poziom 3-13: Finalizacja każdego z atrybutów 
 + 
 +==== General Conceptual Design ==== 
 + 
 +==== V1 ==== 
 + 
 + 
 +==== Directed Conceptual Design ==== 
 + 
 +Kody w PROOGu, kod .dot rysunki ARD/​TPH ​XTT wygenerowane przez VARDA dostępne dodatkowo pod linkiem poniżej 
 + 
 +{{:​pl:​miw:​miw08_ardcase_cs:​elevator.pl|Kod w PROLOGu}} 
 + 
 +{{:​pl:​miw:​miw08_ardcase_cs:​elevator-ard.dot|Plik .dot ARD}} 
 + 
 +{{:​pl:​miw:​miw08_ardcase_cs:​elevator-tph.dot|Plik .dot TPH}} 
 + 
 +=== Full ARD Model === 
 + 
 +ARD: 
 + 
 +<graphviz file="​pl:​miw:​miw08_ardcase_cs:​elevator-ard.dot"​> 
 +</​graphviz>​ 
 + 
 +TPH: 
 + 
 +<​graphviz file="​pl:​miw:​miw08_ardcase_cs:​elevator-tph.dot">​ 
 +</​graphviz>​ 
 + 
 + 
 +==== Refined Conceptual Design ==== 
 + 
 +===== Physical Attribute Specification ===== 
 + 
 +===== Structuralization ===== 
 + 
 + 
 + 
 +===== Logical design ===== 
 + 
 + 
 + 
 + 
 + 
 + 
 +==== V1 ==== 
 + 
 +{{:​pl:​miw:​miw08_ardcase_cs:​elevator-xtt.dot|Plik .dot XTT}} 
 + 
 + 
 +XTT: 
 + 
 +<​graphviz file="​pl:​miw:​miw08_ardcase_cs:​elevator-xtt.dot">​ 
 +</​graphviz>​ 
 + 
 +Plik HQED {{:​pl:​miw:​miw08_ardcase_cs:​elevator-xttml.xttml|XTTML}}
  
  
 +===== Ostatnie zmiany =====
 +24.05.2008 - wersja końcowa, usunięcie linków zewnętrznych,​ dodanie kopii lokalnych
  
 +19.05.2008 - Dopisanie / zmiana opisu, dodanie ARD/XTT
pl/miw/miw08_ardcase_cs/winda.1205107542.txt.gz · ostatnio zmienione: 2019/06/27 15:59 (edycja zewnętrzna)
www.chimeric.de Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0