Lucka Žoltá

Softwarový proces

Proces obecně je po částech uspořádaná množina kroků směřujících k dosažení cíle. Je-li cíl vytvoření softwaru pak mluvíme o softwarovém procesu. Disciplína zabývající se problémy softwarového procesu se nazývá softwarové inženýrství.

Číst dál: Softwarový proces

Struktura překladače

Překladač provádí dvě základní činnosti - analyzuje zdrojový kód a následně jej přeložit do cílového programu. Součástí analýzy je lexikální, syntaktická a strukturální analýza.

Činnost překladače je následující: Zdrojový kód -> pre-procesor -> lexikální analyzátor -> syntaktický analyzátor -> tvorba mezikódu -> optimalizátor -> generování výsledného kód -> optimalizace závislá na zařízení

Součástí generování cílového programu je optimalizace kódu. 

Číst dál: Struktura překladače

Specifikace požadavků

Specifikace a analýza požadavků je první fáze vývoje softwaru. Cílem je definovat požadavky na software a popsat jeho funkčnost. Výsledkem této fáze by měly být dokumenty, které se stanou součásti smlouvy mezi zadavatelem a vývojovým týmem.

Číst dál: Specifikace požadavků

Návrhové vzory

Návrhové vzory jsou metodiky (šablony) pro řešení různých problému, se kterými vývojář může setkat. Objektově orientované návrhové vzory typicky ukazují vztahy a interakce mezi třídami a objekty, aniž by určovaly implementaci konkrétní třídy.

Návrhové vzory se dělí do těchto 3 základních skupin:

• Creational Patterns (vytvářející) - řeší problémy související s vytvářením objektů v systému. Snahou těchto návrhových vzorů je popsat postup výběru třídy nového objektu a zajištění správného počtu těchto objektů. Většinou se jedná o dynamická rozhodnutí učiněná za běhu programu.

• Structural Patterns (strukturální) - představují skupinu návrhových vzorů zaměřujících se na možnosti uspořádání jednotlivých tříd nebo komponent v systému. Snahou je zpřehlednit systém a využít možností strukturalizace kódu.

• Behavioral Patterns (chování) - zajímají se o chování systému. Mohou být založeny na třídách nebo objektech. U tříd využívají při návrhu řešení především principu dědičnosti. V druhém přístupu je řešena spolupráce mezi objekty a skupinami objektů, která zajišťuje dosažení požadovaného výsledku.

Každá z těchto skupin obsahuje mnoho návrhových vzorů, které si nyní rozvedeme:

Creational patterns (Vzory týkající se tvorby objektů)

• Abstract Factory (Abstraktní továrna) – Definuje rozhraní pro vytváření rodin objektů, které jsou na sobě závislé nebo spolu nějak souvisí bez určení konkrétní třídy. Klient je odstíněn od vytváření konkrétních instancí objektů.
• Factory Method (Tovární metoda) – Definuje rozhraní pro vytváření objektu, které nechává potomky rozhodnout o tom, jaký objekt bude fakticky vytvořen. *Tovární metoda nechává třídy přenést vytváření na potomky.
• Builder (Stavitel) – Odděluje tvorbu komplexu objektů od jejich reprezentace tak, aby stejný proces tvorby mohl být použit i pro jiné reprezentace.
• Singleton (Jedináček) – Potřebujete-li, aby měla třída maximálně jednu instanci.
• Prototype (Prototyp, Klon) – Specifikuje druh objektů, které se mají vytvořit použitím prototypového objektu. Nové objekty se vytváří kopírováním tohoto prototypového objektu.
• Lazy Initialization (Odložená inicializace) – Odkládá vytváření objektu, počítání hodnoty nebo provádění nějakého procesu, až do okamžiku, kdy je ho poprvé potřeba.
• Object pool (Fond, lidově bazén) – Umožňuje vyhnout se drahému vytváření a uvolňování zdrojů recyklováním objektů, které už se nepoužívají.
• Multiton

Structural Patterns (Vzory týkající se struktury programu)

• Adapter (Adaptér) – Potřebujete-li, aby spolu pracovaly dvě třídy, které nemají kompatibilní rozhraní. Adaptér převádí rozhraní jedné třídy na rozhraní druhé třídy.
• Bridge (Most) – Oddělí abstrakci od implementace, tak aby se tyto dvě mohly libovolně lišit.
• Composite (Strom, Složenina) – Komponuje objekty do stromové struktury a umožňuje klientovi pracovat s jednotlivými i se složenými objekty stejným způsobem.
• Decorator (Dekorátor) – Použijeme jej v případě, že máme nějaké objekty, kterým potřebujeme přidávat další funkce za běhu. Nový objekt si zachovává původní rozhraní.
• Facade (Fasáda) – Nabízí jednotné rozhraní k sadě rozhraní v podsystému. Definuje rozhraní vyšší úrovně, které zjednodušuje použití podsystému.
• Flyweight (Muší váha) – Je vhodná pro použití v případě, že máte příliš mnoho malých objektů, které jsou si velmi podobné.
• Proxy – Nabízí náhradu nebo zástupný objekt za nějaký jiný pro kontrolu přístupu k danému objektu.

Behavioral Patterns (Vzory týkající se chování)

• Observer (Pozorovatel) – V případě, kdy je na jednom objektu závislých mnoho dalších objektů, poskytne vám tento vzor způsob, jak všem dát vědět, když se něco změní.
• Command (Příkaz) – Zapouzdřete požadavek jako objekt a tím umožněte parametrizovat klienty s různými požadavky, frontami nebo požadavky na log a podporujte operace, které jdou vzít zpět.
• Interpreter (Interpret) - Vytváří jazyk, což znamená definování gramatických pravidel a určení způsobu, jak vzniklý jazyk interpretovat.
• State (Stav) – Umožňuje objektu měnit své chování, pokud se změní jeho vnitřní stav. Objekt se tváří, jako kdyby se stal instancí jiné třídy.
• Strategy (Strategie) – Zapouzdřuje nějaký druh algoritmů nebo objektů, které se mají měnit, tak aby byly pro klienta zaměnitelné.
• Chain of responsibility (Zřetězení zodpovědnosti) – Řeší jak zaslat požadavek bez přesného vymezení objektu, který jej zpracuje.
• Visitor (Návštěvník) – Reprezentuje operaci, která by měla být provedena na elementech objektové struktury. Visitor vám umožní definovat nové operace beze změny tříd elementů na kterých pracuje.
• Iterator (Iterátor) – Nabízí způsob, jak přistupovat k elementům skupinového objektu postupně bez toho, abyste vystavovali vnitřní reprezentaci tohoto objektu.
• Mediator (Prostředník) – Umožňuje zajistit komunikaci mezi dvěma komponentami programu, aniž by byly v přímé interakci a tím musely přesně znát poskytované metody.
• Memento (Memento) – Bez porušování zapouzdření zachyťte a uložte do externího objektu interní stav objektu tak, aby ten objekt mohl být do tohoto stavu kdykoliv později vrácen.
• Template method (Šablonová metoda) – Definuje kostru toho, jak nějaký algoritmus funguje, s tím, že některé kroky nechává na potomcích. Umožňuje tak potomkům upravit určité kroky algoritmu bez toho, aby mohli měnit strukturu algoritmu.

Návrh implementace

Návrh implementace je druhá fáze vývoje softwaru. Jde o abstrakci zdrojového kódu, která bude sloužit jako hlavní dokument programátorům v další implementační fázi.

Číst dál: Návrh implementace

Mapování UML diagramů na kód

K mapování UML diagramů na kód dochází v první části implementační fáze vývoje. Jde o automatické vygenerování zdrojového kódu z UML diagramu.

Z diagramu tříd například vygeneruje jednotlivé rozhraní, třídy s proměnnými a prázdnými metodami. Velmi hezký tutoriál o tom jak se mapuje class diagram na kód najdete zde.

Z diagramů komponent pak vyčte a do generovaného kódu přidá požadované komponenty. Komponenta je už existující a vyměnitelná část systému s daným rozhraním skrze které jí systém používá. Jde o komponentu napsanou v zdrojovém kódu, nebo už zkompilovanou komponentu v binárním kódu, či další komponenty reprezentovanými databázovými tabulkami, dokumenty, apod.

Úkolem samotné implementace je pak dopsat těla metod, jejichž chování může být pospáno v diagramu aktivit.

Číst dál: Mapování UML diagramů na kód

Deklarativní programování

Deklarativní programování se zabývá tím co se počítá a neřeší jak se to počítá (Např. u logického programování definujeme v kódu výrazy a vztahy a pak se dotazujeme na další klauzule, které z toho vyplývají. Jak probíhá samotné vyhodnocení klauzulí se neřeší.). Program je chápan jako funkce, která na základě vstupů vrátí výstup. Stejná funkce se stejnými argumenty dává u deklarativního prog. vždy stejný výsledek (vyhýbají se používání globálních proměnných).

Opakem tohoto principu je imperativní programování popisující jednotlivé úkony pomocí algoritmů. Zjednodušeně to lze popsat tak, že imperativní programy obsahují algoritmy, kterými se dosáhne chtěný cíl, zatímco deklarativní jazyky specifikují cíl a algoritmizace je ponechána programu (interpretu) daného jazyka.

Číst dál: Deklarativní programování

Abstract factory

Abstract factory neboli továrna je návrhový vzor který řeší univerzálnost kódu. Cílem továrny je odstínit klienta od vytváření  konkrétních objektů (to má na starost factory). Klient se nestará o to, které konkrétní objekty vyrábí která konkrétní továrna, protože používá jednotné rozhraní abstraktní továrny. Vzor tudíž odděluje detaily implementace skupiny objektů od jejich obecného používání. 

Příklad Abstract factory:

Jde o to, aby například programátor při změně nějakého grafického prvku, nemusel překopávat celý kód který s tímto prvkem pracuje. Chceme-li mít například univerzální GUI jak pro Windows tak pro Linux, ale v programu nechceme rozlišovat zda pracujeme s linuxovským či windovským tlačítkem. Tuhle univerzalitu zajistím tak, že vytvořím univerzální tlačítko UButton (rozhraní, abstraktní třída), které bude mít definované metody pro práci s tlačítkem. V programu tedy budeme pracovat tlačítkem typu UButton a o konkrétní instanci se postará třída Factory (odtud název návrhového vzoru). Factory na základě operačního systému vytvoří instanci konkrétního tlačítka, které je specializované už pro daný operační systém WinButton nebo LinuxButton. Vzhledem k tomu, že obě tyto třídy implementovaly rozhraní UButton

class WinButton implements UButton

class LinuxButton implements UButton

pracuje s nimi hlavní program jako s jedním typem tlačítka UButton a jestli je to vevnitř WinButton nebo LinuxButton ho nezajímá. 

Překladač

Překladač je program, který překládá programy z jednoho programovací jazyka do jiného. Překladač tedy přečte zdrojový program napsaný v zdrojovém jazyce přeloží ho do ekvivalentního programu (cílový program), který je však napsaný v jiném (cílovém) jazyce. 

Číst dál: Překladač

Singleton

Singleton (česky jedináček) je návrhový vzor, který využijeme při řešení problému, kdy je potřeba, aby v celém programu běžela pouze jedna instance třídy. Tento návrhový vzor zabezpečí, že třída bude mít pouze jedinou instanci a poskytne k ní globální přístupový bod. To můžeme potřebovat například pro různé třídy, které něco řídí a vznik více instancí takovýchto Manager tříd by způsoboval chaos (např. třída zajišťující přístup k databázi) nebo například pro různé messengery apod.

Realizace tohoto návrhového vzoru spočívá v implementaci public konstruktoru a metody getInstance(), která zkontroluje zda ještě nebyla instance vytvořena a podle toho vrátí již existující instanci, nebo vytvoří novou.