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: odkazVaclav 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: odkazVaclav Burda 2014/05/24 15:25

Otázka 1 a 2

Otázka 1 a 2

Pokus o zpracování otázky

* SI 2 (TPJ)

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:

Verze pro tisk ve formátu DOC

Verze pro tisk ve formátu PDF

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)

A4M33NMS 3 - realizujte se

Mírně upravená verze pro tisk, vypustil jsem vzory SOLID, ktere mi prijdou podobne jako GRASP

Pája

Návrhové vzory:

Návrhové vzory na Algoritmy.net

Návrhové vzory na objekty.vse.cz

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)

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)

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)

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)

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)

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

13_web_services.doc

13_web_services.pdf

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

Choreografie vs. Orchestrace

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)

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

Základy testovania

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)

Pája Mrázek - mrazepa1

Otázka 19 ve formátu doc - 100%

Otázka 19 ve formátu pdf - 100%

20. Vhodnost nasazení jednotlivých webových architektur, sdílení dat, perzistence, webové služby a REST, asynchronnost, messaging.(A4M39WA2)

Pája

Ve formátu DOC

Ve formátu PDF

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:

statnice/si.txt · Poslední úprava: 2019/01/10 18:36 (upraveno mimo DokuWiki)
Nahoru
chimeric.de = chi`s home Valid CSS Driven by DokuWiki do yourself a favour and use a real browser - get firefox!! Recent changes RSS feed Valid XHTML 1.0