[csidc:2002] - Ky5a by Dragan Milenkovic <tyrant@galeb.etf.bg.ac.yu>

Ay... jedva poslah mejl...

Ja ne mogu da prisustvujem danas. Daleko je taj BG.
Sad ozbiljno, tek u subotu popodne sam stigao, tako da mi je jos
na pocetku propao ceo plan.

Saljem moj model jezgra, pa vi zasipajte komentarima. Iako nije
kompletan jasno je gde su mu dodirne tacke sa ostatkom programa.
Neka ga neko postavi na plone... nesto ne mogu da nadjem operu. 8-(


Поздрав,
Драган Миленковић

Модел језгра за сада неименованог система

Оно што је описано у овом документу, а што сви називамо "језгро"
садржи минимум функција потребних за координацију возила.

*****************************************************************************************
MessageCenter je Thread
-------------
Процес који прима поруке од возила и прослеђује их одговарајућем
контролном центру (нпр. EventCentru). При томе "прослеђује" значи
позива одговарајућу функцију (нпр. EventCenter.client_respond).

интерфејс:

+ <<create>>(receiver)
    Креира нови MessageCenter који ће поруке дохватати од наведеног
    receiver-а.
+ run()
    Зависно од платформе, нит се покреће на неки начин. Назовимо то run()...


EventCenter је Thread
-----------
Јасно је да је сваки догађај независан од другог. EventCenter врши координацију
возила на терену. Координација подразумева broadcast информација о догађају,
избор возила коришћењем одређеног планера (scheduler-a) и издавање команди.

интерфејс:

+ <<create>>(scheduler, transmitter)
    Kреира нови координатор догађаја који ће расподељивање возила
    вршити наведеним scheduler-ом и користити дати transmitter за 
    комуникацију са њима. Иницијални event_info
    је неки нереални објекат (NullEventInfo) који не захтева
    интервенцију. Први update ће довести до broadcast-a.
    (тј. важи needs_broadcast(NullEventInfo) == true).

+ update_event(new_event_info)
    Врши измену стања догађаја, тј. информација које имамо о датом 
    догађају. Могуће је да се на основу тога изврши поновни broadcast,
    а самим тим и ново планирање.

+ client_respond(respond)
    Прихватање одговора од клијента.

+ run()
    Зависно од платформе, нит се покреће на неки начин. Назовимо то run()...

ДОДАТИ интерфејс за "ручно" слање возила. И дефинисати какав статус имају
таква возила при планирању.

Главни ток
тј. тренутна имплементација у глави аутора. Обратити пажњу да је
битнији интерфејс од имплементације (која увек може да се примени).


                       *
                       |
 +-------------------->|<---------------+
 |                     |                |
 |             ------------------       |
 |            |  чека на update  |      |
 |             ------------------       |
 |                     |                |
 |         крај интерв.|                |
 |     (*)------------< >               |
 |                     |                |
 |                     | није потребан  |
 |                     |  broadcast     |
 |                    < >---------------+
 |                     |
 |                     |<-------------------------+
 |             -----------------                  |
 |            | broadcast новог |                 |
 |            | стања догађаја  |                 |
 |             -----------------                  |
 |                     |                          |
 |      ==============================            |
 |         |                      |               |
 |   -------------        ---------------         |
 |  | прикупљање  |      |чека на update |        |
 |  |  одговора   |       ---------------         |
 |   -------------                |               |
 |         |                      |               |
 |      ==============================            |
 |                     |                          |
 |                     |  ако има update и        |
 |                     | потребан је broadcast    |
 |                    < >-------------------------+
 |                     |
 |       ------------------------------
 |      | планирање позивом schedulera |
 |      |   везаног за овај објекат    |
 |       ------------------------------
 |                     |
 |                -----------
 |               | multicast |
 |               | go/cancel |
 |                -----------
 |                     |
 +---------------------+


Scheduler [абстрактна класа]
---------
Само планирање је независно од прозивања или ажурирања и своди се на то да се
на основу одговора возила и листе активних возила (на том задатку) као и најсвежијих
информација о догађају изврши (АКО ЈЕ ПОТРЕБНО) прерасподела. Нека возила се могу
додати, нека опозвати.

Подсетник: шта планер НЕ СМЕ да ради:
 - Не сме да наизменично наређује возилима стани - крени. Што се службе 94 тиче,
   чак и то једно стани мора да буде врло аргументовано.

интерфејс:

+ schedule(assigned_clients, client_responds, event_info) : <go-list, cancel-list>
    Прерасподела.

EventInfo
---------
Дефинише се у зависности од примене овог система. Једино познато од интерфејса
је одређивање потребе за поновну прозивку возила и да ли је догађај "опслужен".

интерфејс:

+ is_server() : bool
    Више није потребно интервенисати.

+ needs_broadcast(old_event_info, new_event_info) : bool

    При овоме поштовати следеће ограничење (нешто као транзитивност):

       ---  update   ---  update   ---
      | A |-------->| B |-------->| C |
       ---           ---           ---

        not needs_broadcast(A,B) /---\
    and not needs_broadcast(B,C) \---/ not needs_broadcast(A,C)



*****************************************************************************************
Комуникационе примитиве

MessageReceiver
---------------
Пријемник релативно кратких порука од клијената (возила).

интерфејс:

+ receive(timeout [=oo]) : <client, data>
    позив се блокира ако нема порука

MessageTransmitter
------------------
Предајник релативно кратких порука до клијената (возила).

интерфејс:

+ send(client, data, timeout [=oo])

+ broadcast(data, timeout [=oo])

+ multicast(client-list, data, timeout [=oo])

*****************************************************************************************
Кориснички интерфејс, тј. како језгро интерагује са оператером.

Користимо listener-е. Ако неко хоће да прати промене у контролном
центру, региструје се као слушалац.... Ма знате то из Јаве...
ОБО ЈЕ САМО ТЕМПЛЕЈТ. Како ће бити на крају зависи од одговора
на питања која ми се тренутно врзмају по глави.

Наравно, listener подразумева да објекти које ослушкујемо имају
нешто као add_listener(l) иако то није наведено у тексту изнад.

EventCenterListener
-------------------
+ client_assigned(client)
+ client_canceled(client)
+ client_connection_problems(client)

KakodaganazovemListener
-----------------------
+ new_event(event_center)
    Прати долазак нових интервенција...
+ event_served(event_center)
    ... и њихову потенцијално успешну реализацију.

*****************************************************************************************