navigation
hledat
Obsah
1. (Nový studijní plán) Sémantika: operační sémantika, denotační sémantika, pevný bod funkce, vázání jmen, stav, tok a data programu. (A4M36TPJ)
nějaké moje výpisky, kdyžtak doplňte/opravte: odkaz — Vaclav Burda 2014/05/24 15:25
2. (Nový studijní plán) Statická sémantika: typy, polymorfní typy, typy vyššího řádu, rekonstrukce (inference) typů, abstraktní typy, moduly, efekty. (A4M36TPJ)
nějaké moje výpisky, kdyžtak doplňte/opravte: odkaz — Vaclav Burda 2014/05/24 15:25
Pokus o zpracování otázky
3. (Nový studijní plán) Teorie HCI, kognitivní aspekty, způsoby interakce, speciální uživatelská rozhraní. (A4M39NUR)
4. (Nový studijní plán) Metody návrhu, uživatelské a konceptuální modely. (A4M39NUR)
5. (Nový studijní plán) Formální popis uživatelských rozhraní. (A4M39NUR)
6. (Nový studijní plán) Pokročilá uživatelská rozhraní (inteligentní uživatelská rozhraní, multimodální uživatelská rozhraní). (A4M39NUR)
7. (Nový studijní plán) Metody testování uživatelských rozhraní a jejich vyhodnocování, standardizace. (A4M39NUR)
1. Uživatelské požadavky, definice funkcionality systému, vztah mezi funkcionálními a nefunkcionálními (např. kapacita, škálovatelnost, robustnost) požadavky na systémy, technická specifikace.(A4M33NMS)
2. Unified Modeling language (UML), popis jazyka, typy diagramů a způsob jejich použití při návrhu různých aspektů systému, syntax a sémantika jazyka a jeho symbolů.(A4M33NMS)
janskpe1 A4M33NMS 2 - 100%
Hodil jsem to do PDF a do Wordu a z 20 stranek jsem to zmensil na 5, aby se z toho dalo ucit. Otazka byla asi nejeky copy-paste z nejake ucebnice:
Pája
3. Objektově orientovaný návrh software, metodiky objektového návrhu, postupy rozvinutí technické specifikace na úrovni modulů do detailního objektového návrhu, návrhové vzory (design patterns).(A4M33NMS)
Mírně upravená verze pro tisk, vypustil jsem vzory SOLID, ktere mi prijdou podobne jako GRASP
Pája
Návrhové vzory:
4. Interní a externí systémová rozhraní, zásady návrhu rozhraní, komponentový přístup, jeho návrh a formalismy, integrace subsystémů.(A4M33NMS)
belohji1
Enterprise application integration - Wikipedia, the free encyclopedia
Napadá mě, že integrace systémů (webových služeb) může probíhat pomocí BPEL. Tím vznikne nová agregující nebo orchestrující služba. Integrované služby nevědí o tom, že jsou součástí nějakého většího celku. Prostě jen přes své rozhraní poskytují službu, která by měla být stateless.
relevantní zdroje
5. Synchronní a asynchronní distribuované systémy, specifika návrhu a vlastností distribuovaných systémů, integrace externích datových zdrojů.(A4M33NMS)
belohji1
Integrace externích datových zdrojů
Článek o distribuovaných systémech v Javě
Architektury distribuovaných systémů - PDF prezentace
Přehledné porovnání RPC, CORBA, RMI...
X33MEP - distribuovane programovani, middleware
pozn: tou integraci externich zdroju se fakt mysli LaV a GaV (tj. nematerializovane pohledy na zdroje), tak bacha na to…
6. Techniky správy a organizace rozsáhlých softwarových projektů. Nástroje pro správu verzí a vývojových větví zdrojových kódů, nástroje pro automatické generování dokumentace a podporu orientace v rozsáhlých projektech. Infrastruktury zajišťující spolupráci mezi vývojáři navzájem a i s uživateli. Systémy pro sledování a řešení chyb a uživatelskou podporu.(A4M35OSP)
founemi2
6_techniky_spravy_a_organizace_rozsahlych_softwarovych_projektu_3.doc - 100%, doplněna motivace a kontinuální integrace
6_techniky_spravy_a_organizace_rozsahlych_softwarovych_projektu_3.pdf
7. Požadavky a pravidla pro tvorbu přenositelného kódu. Organizace projektů a operačních systémů pro splnění přenositelnosti mezi různými architekturami CPU. Konverze vnitřních a vnějších/síťových formátů dat.(A4M35OSP)
8. Ekonomické aspekty informačních systémů - výnosy z provozování systému, celkové náklady vlastnictví systému (TCO), návratnost investic, náklady spojené s výpadky, kapacitními problémy a chybami.(A0M33PIS)
Nová verze, zkráceno z 13 na 4 strany
Kdo se chce učit ze slidů, tak je to přednáška 2 a strana 26 ve sborníku přednášek z PISu http://agents.felk.cvut.cz/wiki/lib/exe/fetch.php?id=teaching%3Apis&cache=cache&media=teaching:pis:predn:a0m33pis_komplet.pdf
9. Prumyslové aspekty IS, nefunkcionální požadavky na systémy podle ISO 9126, kapacitní plánování systémů, zajištění odezvy a škálovatelnosti systému.(A0M33PIS)
10. Stabilita a spolehlivost systému, MTBF (mean time between failures), dostupnost systému (uptime), redundance, návrh vysoce robustních systémů.(A0M33PIS)
kobetvla - OI_SI_PIS_Stabilita_Spolehlivost_Systemu
11. Systémy pro manažerské rozhodování: data mining, řízení rizika, enterprise resource planning (ERP) systémy, customer relationship management (CRM) systémy.(A0M33PIS)
janskpe1 A0M33PIS 4 - 100%
12. Co je to architektura zaměřená na služby (SOA)? Základní pojmy, vztah k objektově orientované architektuře. Konceptuální model a formalismy pro modelování SOA.(A4M33AOS)
Zdroje:
- přednášky
- otázka 13
- MatFyz, Martin Nečaský: http://oi-wiki.cz/lib/exe/fetch.php/statnice/lecture_swi108_semantic_web_services.pdf
13. Webové služby. K čemu slouží? Popis a vyhledávání služeb. Co je a k čemu slouží orchestrace a choreografie služeb. Technologie pro implementaci služeb.(A4M33AOS)
pokorpe6
Otázka zpracovaná ve formě poznámek
Otázka zpracovaná ve formě poznámek
Nevim co je presne mysleno technologiemi pro implementaci WS. WS technologie jsou popsany v predchozich kapitolach. Nejaky napad co tam doplnit ??
- Poslední kapitola je rozpuštěná do těch ostatních, takže když ji smažeme, nic se nestane. Pája
- Dle mého názoru: pro Javu využíváme knihoven JAXB (Java Architecture for XML Binding) a JAX-WS pro samotné budování WS
14. Sémantické webové služby. Rozdíl oproti klasickým webovým službám. Výběr sémantických webových služeb, automatická kompozice služeb.(A4M33AOS)
15. Architektura zaměřená na služby (SOA). Kvalita služeb (QoS), výběr založený na QoS, sociální výběr služeb, trust a reputace v otevřených SOA.(A4M33AOS)
janskpe1 A4M33AOS 2 - 100% ?
16. Kategorizace SW chyb, kriteria korektnosti a pouzitelnosti, spolehlivost SW(A4M33TVS)
janskpe1 A4M33TVS 1 - 100%
Pájův domácí testovací guláš (opraveno, zformátováno, zkráceno a někde doplněno):
17. Testování metodami bílé a černé skřínky. Strukturální, statická a dynamická analýza. Analýza datových toků. Zátěžové testy.(A4M33TVS)
http://oi-wiki.cz/doku.php/statnice/si/a4m33tvs2
Metriky enterprise systémů (co měřit při zátěžových testech)
Příklad dokumentu Zátěžové testy k mojí diplomce. Je vidět co se měří a pomocí jakých nástrojů: http://www.uschovna.cz/download/EBTFSLAV88Y75M6P-BWA/GCYBYFJTLK
MAPOVÁNÍ jednotlivých bodů otázky na probraná témata - jako např.:
Strukturalní analýza: Strukturální testování - řídicí tok (cv4), datový tok (cv5)…
Statická analýza: Model checking, testovani konecneho automatu (cv7)…
Dynamická nalýza: Test bezici aplikace (AUT – application under test)
founemi2
Ptal jsem se pana Maříka na to strukturální, statické a dynamické testování, zde je jeho odpověď:
Dobry den, pane Micka,
Do strukturalni analyzy pro ucely testovani lze zahrnout vse, kdy se specifikace software, architektura (napr. UML, ci I slovni MS Word dokument), kod, a jine artefakty podrobi procesu, jehoz vysledkem jsou struktury (typicky v nejake forme grafu jako ridici tok, datovy tok, sekvencni diagramy, stavove automaty, atd.). Tyto struktury slouzi pak jako vstupni data pro konstrukci testu.
Staticka analyza pak vychazi z vychozich specifikaci, diagramu, kodu, ktere se v case nemeni.
Dynamicka analyza vychazi z bezici aplikace (AUT – application under test). Na zaklade pozorovani chovani lze pak konstruovat “grafove” struktury rovnez (napr. identifikace stavoveho automatu, ruzne modely uceni, atd.). Mezi konkretni metody patri napriklad metody chybneho pouziti pameti (ukazatele, meze poli ala kontroly v MS Visual Studiu ci Rational Purify ci Boundchecker)
Pod statickou nestrukturalni metodou si muzete predstavit napr. testovaci procedury sestrojene na zaklade uzivatelskeho manual, ktery vlastne jenom overuji, ze dana operace popsana v manual skutecne ma za vysledek to, co se tam pise. Rovnez by sem zrejme patrily vsechny metody revizi, atd.
Nesnazte se vsak takto vymezene pojmy brat jako definovane na 100%, nebot si rovnez umim predstavit radu metod, ktere do takoveho schemata proste nezapadaji. V cemkoliv nestrukturalnim z jednoho pohledu vzdy lze nalezt nejakou strukturu z jineho pohledu a naopak. Mam-li to dokumentovat na bezne zalezitosti – ve Vasem pokoji ma z Vaseho pohledu urcite vse sve misto a poradek, zatimco z pohledu Vasi matky to muze byt pocitovano jako chaos (treba to neni ale Vas pripad J, pak se omlouvam).
Zdravi
Radek Marik
18. Formální specifikace programu. Verifikace pomocí metod automatického dokazování a metody model-checking.(A4M33TVS)
19. Architektura Java EE, funkce jednotlivých vrstev, životní cyklus standardizovaných komponent Java EE, návrhové vzory využitelné v architektuře webové aplikace.(A4M39WA2)
20. Vhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging.(A4M39WA2)
Pája
formulace „Vhodnost nasazení jednotlivých webových architektur“ znamená podle Klímy toto:
Dobry den, predstavuji si to tak, ze nastinite urcite tridy problemu, které se v praxi vyskytuji a jejich moznost nasadit do nejakeho prostredi, které ma, mimo jiné, webove rozhrani. Uvedu priklad: elektronicke bankovnictvi, které ma mit pro klienty i webove rozhrani. Takovou aplikaci asi tezko budu koncipovat jako ciste webovou. Místo toho zvolim architekturu, která bude mit v pozadi nejaky aplikacni server. Dále muzu uvazovat o tom, co je jak moc zatizene při rustu poctu klientu, rustu banky apod. Podle toho jako moznou variantu mohu navrhnout například prechod do privatniho cloudu, verejneho cloudu apod. Jiny priklad: eshop, vypocet fraktalnich obrazcu přes web, něco jako youtube
cau, akorat to procitam – Hibernate jde konfigurovat i anotacema, iBatis asi taky…u appengine datastore bych napsal, ze JDO a JPA je spis trapnou parodii na tyhle standardy. Jinak je to super, diky. – mickapa1
ad REST: přidal bych tam že definuje 5 podmínek (constraints):
- Client-server (aplikační logika rozdělená mezi server a klient),
- Stateless (bezestavová komunikace - jeden požadavek nese všechny informace které server potřebuje k jeho zpracování),
- Cache (odpovědi serveru nesou informaci zda mohou být někde po cestě uloženy),
- Uniform Interface (adresujeme resources pomocí URI, manipulujeme s resources pomocí jejich reprezentací (v JSON, HTML…) užitím HTTP metod (GET, POST, PUT, DELETE),
- Layered System (možnost výskytu load balancerů, proxy… aniž by tyto prvky aplikaci jakýmkoli způsobem zajímaly),
- Code-On-Demand (nepovinná) - server může poskytnout kód, který klient spustí (ale REST neříká jak to realizovat).
CHYBY v pdf:
- komunikace klient – server, klient i server jsou stateless - komunikace je stateless, ale klient i server mohou samozřejmě držet nějaký svůj stav. Server rozhodně nedrží žádný stav klienta.
- linky obsahují sémantickou informaci, např. mujweb.cz/delete/person/321 - linky adresují resource, neurčují jejich operace ⇒ slovesa by se v linku neměla vyskytnout (správně je naprř. mujweb.cz/person/321). Sémantickou informaci bych v souvislosti s URI vůbec nezmiňoval.
- pro create lze využít i HTTP PUT (rozdíl PUT na mujweb.cz/person/1 vs POST na mujweb.cz/person/).
Lu2
Ad REST: Rest je architektonický návrhový vzor. Klíčovou vlastností jsou URI a hypertext, tedy že jeden resource linkuje další. Jinak je to jen CRUD nad HTTP (CRUD = Create-Read-Update-Delete). Zjednodušeně lze říct, že URI je podstatné jméno a HTTP metoda je sloveso.
21. Cloud architektury, virtualizace, různá pojetí cloudových řešení, omezení cloudových aplikací, náklady na provoz, vlastnosti aplikací vhodných pro nasazení v cloud architektuře.(A4M39WA2)
— Marek Sacha 2011/05/27 15:56
Tvorim dokument, kdyby se nekdo chtel pridat muzete volne editovat.
https://docs.google.com/document/d/1v3kWgsxv67yEE10eLNGlU0HIaYy_OC1C5j8QX9k9ZSg/edit?hl=en_US
OI-wiki kopie z 18.1.2013:
