|
Projekty /
FescaPaperAhoj Ondro, diky moc za komentare, jsou podstatne. Jsem chvili online ale nemam uz silu na tom dneska delat :-/ Takze jen pisu reply na komentare a zas odpadnu; do textu se pustim rano. Ale kdyz to vidim v globalu tak mam ted vazny dojem ze to nejde stihnout... Premek (Doufam ze mam spravne cisla radku, beru to z Eclipsu ktery se snazi zalamovat ty dlouhe radky tak to nemusi sedet.) line 138 %ORO Ta cast ze sobotniho chatu s Premkem by sla leda sem (pokud nechci intro prepsat cele) -- jo, ja tam dopisu ty dusledky, to bude stacit line 566 %ORO: Chteli jsme se vyhnout string jako typu pro hodnoty -- OK bude to bez string, jen enum. taky jsem si rikal ze se mi string nelibi, puvodne tam byl "char" coz nechci, je k nicemu -- a nemel jsem u sebe ty svoje poznamky a hlava uz moc nepremyslela line 576 %ORO: Jednotky, jako string ano, ale s namespace. -- cela property musi byt v namespace, potazmo bude i jeji measurement unit line 602 %ORO: We are NOT SURE since what we present here is a ``paperware''. It is fair to say that in principle $p_i$ can be a derived property, but so far we keep is simple and disallow it. -- well said, udelame tak line 611 %ORO TBD -- this example on time and memory is bad -- souhlas; zkusim on the fly vymyslet nejaky smysluplny, asi by sel okopiroavt+preformulovat z NoFun nebo jineho paperu line 620 %ORO Na schuzce jsem propagoval myslenku, ze v kazdem registry muze autor uvest i mapping mezi jeho propeties a properties z jineho registry. ... cokoliv k tomu navrhneme by slo prodat jako dalsi contibution. -- ja bych drzel KISS a mapovani bych nechal dle navrhu na dalsi contribution; krom uvedene weakness to potenciale vede na funkce a prepoctove vzorce a to bych si radsi 2x promyslel line 634 ORO ... EFP by tak mohle byt ctverice namisto trojice, kde ctvrta polozka je ``context''. -- good idea. Takhle je to z pohledu te EFP samotne, ona se muze vyskytovat v ramci component specification (viz CoSi) kde je kontext dany mistem vyskytu, ale do definice to dame protoze to umozni potencialne decoupling of EF spec from functional (interface) spec. line 641 %ORO ``worse case'' is not the best term here ... would rather name the property ``max_memory_consumption''. In fact, I would even compare the propety names ``memory'' and ``max_memory_consumption'' -- good point, takhle jsme to rikali na schuzce; prepisu line 650 %ORO We completely omitted discussion on the ``composition rules'' [mapping EFPs from required to matching provided features] -- good catch, to tam musi byt, dopisu line 656 %ORO Taky jsem si kreslili obrazek, kde vetsi komponenta je slozena z nekolik jednoduchych -- na to se podivam, taky good catch |