Grants: finished » Grant Dziekański 2012: DisCODe MDE

2. Brak elementu typu "Connection" w metamodelu
- jest to konsekwencja 1.

3. Umożliwienie połączeń *-* pomiędzy InputPort a OutputPort'ami

4. Wprowadzenie pojęcia kompozytu
- zawiera wiele komponentów,
- na zewnątrz widoczne są porty oznaczone jako relacja Delegate (InputPort) oraz Propagate (OutputPort)
- nie będzie istniał de facto taki twór od strony oprogramowania, ma być wykorzystany mechanizm opisu komponentu (np. plik XML)

5. Handler'y w komponentach
- Priorytety handler'ów: kolejność wywołań związana jest z ich kolejnością w samym modelu (pierwszy od góry ma najwyższy itd.)
- komponentu typu "Source" jest tak naprawdę wywiedziony z faktu, iż dokładnie jedną metodę "bez pobudzeń"
- możemy wykrywać klika źródeł w wątku i produkować "ostrzeżenie" dla projektanta systemu

6. Dwie propozycje:

a) "Całkowite uporządkowanie" komponentów
- każdy komponent ma cyferkę, która nie jest "priorytetem", tylko jest związana z "kolejnością odpalenia" (order)

b) Priorytety względne
- wszystkie komponenty mają domyślny priorytet
- w przypadku gdy projektant układu ma wiedzę/chce wymusić kolejność, istnieje mechanizm zaznaczania "który komponent ma być odpalony przed którym"
- potencjalnie można zaznaczyć relacje między wszystkimi komponentami => poprawność relacji łatwa do automatycznego zweryfikowania
- to wystarcza do wyliczenia priorytetów wszystkich komponentów
- propozycja algorytmu szeregowania: round-robin z kolejkami priorytetowymi

Wybieramy b)

7. Mechanizm "subtask"
- wprowadzenie relacji między subtaskami -> "or" domyślna, "xor" do ustawienia

8. Mechanizm zegara
- komponent w oddzielnym wątku

X. Szeregowanie komponentów
- wprowadzenie stanu komponentu "bizi"/"niebizi"
- wykorzystanie idei puli wątków
- wątek "koordynatora" biegający po komponentach i odpalający wątki z komponentami
- być może nie jest potrzebny watke "managera" - to może zaoszczędzić przełączenia kontekstu
- informacja o tym, że coś może być odpalone może pochodzić z a) zakończonego handlera, b) przyjściu nowych danych (w szczególności spoza systemu)

Przy artykule o metamodelu należy koniecznie podkreślić zastosowanie brzytwy ockhama do skasowania polis(!)

Tomasz Kornuta napisał:

1. Uproszczenie InputPort'u
- skasowanie mechanizmu kolejkowania -> kolejka może być zrealizowana jako komponent szablonowy typu "kolejka"

Tomasz Kornuta napisał:

6. Dwie propozycje:

a) "Całkowite uporządkowanie" komponentów
- każdy komponent ma cyferkę, która nie jest "priorytetem", tylko jest związana z "kolejnością odpalenia" (order)

b) Priorytety względne
- wszystkie komponenty mają domyślny priorytet
- w przypadku gdy projektant układu ma wiedzę/chce wymusić kolejność, istnieje mechanizm zaznaczania "który komponent ma być odpalony przed którym"
- potencjalnie można zaznaczyć relacje między wszystkimi komponentami => poprawność relacji łatwa do automatycznego zweryfikowania
- to wystarcza do wyliczenia priorytetów wszystkich komponentów
- propozycja algorytmu szeregowania: round-robin z kolejkami priorytetowymi

Wybieramy b)

Kolejność (w przypadku komponentów) VS Priorytety (w przypadku funkcji przejścia w danym komponencie)

Tomasz Kornuta napisał:

X. Szeregowanie komponentów
- wprowadzenie stanu komponentu "bizi"/"niebizi"
- wykorzystanie idei puli wątków
- wątek "koordynatora" biegający po komponentach i odpalający wątki z komponentami
- być może nie jest potrzebny watke "managera" - to może zaoszczędzić przełączenia kontekstu
- informacja o tym, że coś może być odpalone może pochodzić z a) zakończonego handlera, b) przyjściu nowych danych (w szczególności spoza systemu)

Zwracanie TRUE/FALSE w przypadku gdy komponent odpalił/nie może odpalić żadnej funkcji - to może być potrzebne w przyszłości w przypadku "pracy krokowej"

Tomasz Kornuta napisał:

6. Dwie propozycje:

a) "Całkowite uporządkowanie" komponentów
- każdy komponent ma cyferkę, która nie jest "priorytetem", tylko jest związana z "kolejnością odpalenia" (order)

b) Priorytety względne
- wszystkie komponenty mają domyślny priorytet
- w przypadku gdy projektant układu ma wiedzę/chce wymusić kolejność, istnieje mechanizm zaznaczania "który komponent ma być odpalony przed którym"
- potencjalnie można zaznaczyć relacje między wszystkimi komponentami => poprawność relacji łatwa do automatycznego zweryfikowania
- to wystarcza do wyliczenia priorytetów wszystkich komponentów
- propozycja algorytmu szeregowania: round-robin z kolejkami priorytetowymi

Wybieramy b)

Poprawka - wybieramy A! Parametr Kolejność (k) związana z....? wątkiem czy podzadaniem? Ja jestem za wątkiem...