nějaké moje výpisky, kdyžtak doplňte/opravte: odkaz — Vaclav Burda 2014/05/24 15:25
nějaké moje výpisky, kdyžtak doplňte/opravte: odkaz — Vaclav Burda 2014/05/24 15:25
Pokus o zpracování otázky
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
Mírně upravená verze pro tisk, vypustil jsem vzory SOLID, ktere mi prijdou podobne jako GRASP
Pája
Návrhové vzory:
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.
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…
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
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
kobetvla - OI_SI_PIS_Stabilita_Spolehlivost_Systemu
janskpe1 A0M33PIS 4 - 100%
Zdroje:
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 ??
janskpe1 A4M33AOS 2 - 100% ?
janskpe1 A4M33TVS 1 - 100%
Pájův domácí testovací guláš (opraveno, zformátováno, zkráceno a někde doplněno):
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
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.
— 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: