Aktuální kategorie: Ostatní

Ztratíte-li se na webu, vede tato zkušenost, tak jako ve "skutečném" životě, k frustraci a hněvu, což může vyústit až v odmítnutí dalších návštěv. Navigační systémy pomáhají uživateli v orientaci, ukazují mu, kde se nachází a kam může jít. Navigačních systémů a možností jejich technické realizace je však velké množství, proto je také důležité se dobře rozhodnout, jakou kombinaci zvolit.

Označování (pojmenování) je forma reprezentace. Například nápis "Kontaktujte nás" reprezentuje souhrn informací, který obsahuje kontaktní osobu, adresu, telefon a e-mail. Místo uvedení těchto informací na každé stránce uvedete jen nadpis, který je reprezentuje. Slouží jako zkratka, která vyvolá asociaci.

WebML patří mezi poměrně malou skupinu metodologií určených pro analýzu a návrh webových aplikací, které byly přeneseny z oblasti akademických debat až do úspěšného využití v praxi. Nemalý podíl na tom jistě má i kvalitní CASE nástroj WebRatio, který umožňuje plynulý přechod od analýzy a návrhu k implementaci samotné webové aplikace. V  několika předchozích článcích byl věnován prostor především metodologii jako takové. Vysvětleny byly jednotlivé modely, které se při návrhu aplikace musí vytvářet. Tentokrát se podíváme především na prostředí WebRatio.

Informační architektura je hlavně o organizování a získávání informací - obsahu. Ty se snaží z vašeho systému dostat uživatel. Obsah i uživatel existují v určitém kontextu. U uživatele jsou to jeho zvyky, zkušenosti a potřeby, u obsahu například velikost, formát, existující struktury, vlastnictví a firemní pravidla. Tolik pro začátek. Dále raději přeskočím všechny nudné teoretické úvody a vrhnu se rovnou na základní artefakty...

V předchozích článcích popisované diagramy případů užití jsou pomůcky pro rychlou orientaci ve funkčních požadavcích na systém, jejichž významovým podložím musí být podrobný textový popis případů užití. Tento článek vybočuje ze zaměření série na návrh aplikací v UML, protože UML žádnou normalizovanou osnovu pro textové případy užití nenabízí, a proto budu vše vysvětlovat na šabloně, jejíž současnou strukturu můžete považovat za jednu z inkarnací mých zkušeností z projektů, na kterých jsem se podílel.

V předchozím článku jsem se zabýval jednoduchými diagramy případů užití, jejichž hlavní předností je přehlednost pro všechny zainteresované. Komplikovanější systém však vyžaduje, abychom nalezli složitější vztahy mezi případy užití a aktory, protože jinak se z diagramu stane odpudivá a sémanticky rozplizlá pavučina zkonstruovaná z překřížených čar a oválů. Intuitivní orientace v tom, jaké funkční požadavky systém pokrývá a kdo se na nich podílí, bude pro každého účastníka projektu ztížená a u extrémně složitých systémů nemožná.

Předchozí články o WebML se zabývaly modelováním těch částí webové prezentace, jejichž jediným účelem je prezentovat data, nikoli s nimi manipulovat. Prezentace dat nám ovšem ve většině případů nestačí, i jednoduché aplikace vyžadují provádění nejrůznějších operací s daty (vkládání, editace a mazání záznamů). Tento článek se bude snažit představit základní principy modelování webových aplikací, jejichž účelem je manipulace s daty, tedy například systémy typu Content Management.

Předchozí článek o WebML byl věnován základním principům a vlastnostem navigačního modelu. Protože navigační model představuje nejdůležitější část návrhu webové aplikace, budeme v jeho výkladu pokračovat i v tomto článku. Pokusíme se osvětlit problematiku oblastí, pohledů na webovou prezentaci a dalších způsobů zpřehlednění struktury rozsáhlých hypertextových aplikací. Dostaneme se také ke způsobu definice navigačního menu webové prezentace.

Hic Sunt Leones - zde jsou lvi. Touto větou Římané označovali neprobádaná teritoria na mapách. Při návrhu každého systému musíme zpočátku logicky utřídit množství mlhavých a navíc chaoticky vyslovovaných požadavků zákazníka na funkce, které by měl systém obsahovat. Svět se příliš nezměnil, před námi je neznámá oblast a když ji dokonale nezmapujeme, na konci neúspěšného projektu pochopíme, že v ní zůstali i lvi. Hlavní funkční požadavky na systém jsou v UML zachyceny v případech užití (Use Case).

Navigační modelování představuje pravděpodobně nejdůležitější součást procesu analýzy a návrhu internetové aplikace. V metodologii WebML vytváří navigační model společně s modelem kompozice komplexní hypertextový model. V tomto článku se vám pokusím přiblížit, jakým způsobem se vytváří hypertextový model.

Tématem tohoto článku jsou řízená rozšíření jazyka UML, která jsou posledními obecnými pravidly (mechanismy). V praxi se při navrhování různých typů aplikací neustále potýkáme s požadavkem na vyjádření netriviálních faktů, pro jejichž sémantiku není v jazyce UML přímá podpora. Řízená rozšíření překlenují propast mezi všeobecně známými standardními elementy jazyka UML a naší snahou přiměřeným způsobem zohlednit ve vytvářeném modelu charakteristické a specifické aspekty problémové domény.

V předchozím článku o WebML jsem popisoval datový model WebML, který tvoří základ analýzy a návrhu internetové aplikace. Návrhem datové struktury analýza samozřejmě nekončí. Jako další se vytváří model hypertextový, popisující celkovou strukturu a funkčnost internetové aplikace. Hypertextový model se skládá ze dvou neoddělitelných součástí, navigačního modelu a modelu kompozice (struktury) webové aplikace, kterému věnuji tento článek.

Předchozí článek se snažil váhajícímu i skeptickému čtenáři prezentovat výhody analýzy a návrhu softwarových systémů v jazyce UML. Nepsaným mottem článku byl apel "opusťte archaické způsoby tvorby aplikací". Tento a následující články jsou již orientovány na čtenáře, který se rozhodl, že návrh pomocí UML se stane fundamentální součástí jeho analytické výzbroje. V tomto článku se soustředím na popis základních stavebních bloků a obecně platných pravidel v jazyce UML.

Datové modelování představuje jednu ze základních součástí analýzy každého softwarového projektu, tedy i projektu, jehož cílem je vytvořit internetovou aplikaci. Správný návrh datové struktury může do značné míry ovlivnit bezporuchovost, udržovatelnost a rozšiřitelnost výsledné aplikace. Jak se s touto problematikou vypořádala metodologie WebML, se dozvíte v následujícím článku.

Hledáte marně nějaký nástroj pro analýzu a návrh vašich internetových projektů? Přijde vám UML k tomuto účelu příliš robustní a složité, ale zároveň v některých ohledech nedostačující? Pojďme se společně podívat, co nám softwarové inženýrství nabízí v oblasti vývoje webových aplikací. Následující série článků by vás měla seznámit se základní filosofií a strukturou metodologie WebML.

"Kvalitní objektově orientovaný návrh aplikace je nezbytným předpokladem jeho úspěšné implementace". Tuto floskuli pravděpodobně slyšel každý, kdo se vývojem aplikací zabývá profesionálně. I v přetechnizované IT oblasti je módní používat libozvučná magická zaklínadla, jež mají zákazníka utvrzovat v profesionalitě dodavatele, který ale často není schopen dostát nárokům kvalitního návrhu, zato se brilantně orientuje v PR frázích a zná nazpaměť aktuální slovník buzzwords. Ambicí této série článků je očistit větu o kvalitním návrhu od otravných pseudomarketingových zplodin a ukázat skutečné výhody precizně provedeného návrhu pomocí modelovacího jazyka UML.

Dnes bych vás rád seznámil s úžasnou nejmenovanou 3D hrou, v níž hráč ovládá tučňáka, který klouže po břiše závodní drahou a cestou loví sledě. Poslední článek nás totiž definitivně odpoutá od mlhavých ideálů, vznešených hodnot a nekonstruktivních povzdechů z článků předchozích, pustíme se do konkrétních návodů, které nám přináší extrémní programování. Tedy vzhůru na sledě.

Pokud připravujeme aplikaci, která vyžaduje v průběhu celé práce s ní jasnou identitu uživatele (chat, webový e-mail, práce s bankovním účtem), je bezpodmínečně nutné mít na paměti několik pravidel, která zabrání, aby někdo podvrhl cizí identitu. To je možné tak, že útočník zcizí identitu jinému uživateli. Pro ověřování identity uživatele se používají takzvané sessions. Proto útokům, které zcizují identitu v sessions říkáme "session-stealing". Jak se jim ubráníte, se dozvíte v následujících řádcích.

Pokud se přihlásíme k aplikaci pomocí standardní HTTP autentizace, prohlížeč si jednou zadané údaje (ať už do URL nebo do přihlašovacího dialogu) zapamatuje a při každém volání nějaké stránky z téhož serveru předává aplikaci jméno a heslo. Zkusme se podívat, jak lze prohlížeč přesvědčit, aby "zapomněl".

Už na úrovni klienta je možné provést některé kontroly pomocí JavaScriptu, které testují, zda uživatel vyplnil správné a adekvátní údaje. Tyto kontroly jsou ale jen důležitým "kosmetickým" doplňkem. Pokud chce někdo "nabourat" vaši aplikaci, jsou neúčinné. Metodě, kdy někdo podvrhne falešné nebo nebezpečné parametry aplikaci, říkáme "script injection".

Velice častou chybou v případech, kdy zobrazujete nějaký vstup od uživatele přímo, bez jakékoli kontroly, je, že uživatel může do textu vložit nějaké HTML tagy, ale také povely JavaScriptu (!). Populární je nastavení barvy písma na barvu podkladu, vložení nějakého hodně velkého a nebo hodně "obnaženého" obrázku apod.

V následujícím seriálu probereme možnosti a problémy zabezpečení aplikací. Ačkoli je řada bezpečnostních problémů zaviněna samotným programátorem, začneme seznámením s metodou zabezpečeného přenosu SSL.