Metodika. Architecture First. Rudolf Pecinovský

Metodika

Architecture First Rudolf Pecinovský [email protected] Copyright © Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze 1.00.2413, uloženo po 9.6.2014 – 14:43

1 z 39

Obsah 1. Kapitola 2. KONEC

Copyright © Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze 1.00.2413, uloženo po 9.6.2014 – 14:43

2 z 39

1.

Motivace

Obsah 1.1 Vývoj IT podpory našich činností 1.2 Časté problémy 1/2 1.2.1 Typická situace 1/3 1.3 Správný postup 1.4 Kde je problém s přecházením na nový styl – konstruktivismus


3 z 39

1.1 Vývoj IT podpory našich činností ► Počítače a jejich programy postupně přebírají

stále větší a větší část našich pracovních činností


4 z 39

1.1 Vývoj IT podpory našich činností ► Počítače a jejich programy postupně přebírají


► Tento trend můžeme pozorovat i v oblasti vývoje programů


5 z 39

Vývoj IT podpory našich činností ► Počítače a jejich programy postupně přebírají


► Tento trend můžeme pozorovat i v oblasti vývoje programů ● Na počátku jsme museli navrhovat programy přímo ve strojovém kódu


6 z 39



► Tento trend můžeme pozorovat i v oblasti vývoje programů ● Na počátku jsme museli navrhovat programy přímo ve strojovém kódu, ● posléze se objevil assembler a různé autokódy ● následované vyššími programovacími jazyky,


7 z 39



► Tento trend můžeme pozorovat i v oblasti vývoje programů ● Na počátku jsme museli navrhovat programy přímo ve strojovém kódu, ● posléze se objevil assembler a různé autokódy ● následované vyššími programovacími jazyky, ● stále rozsáhlejšími a dokonalejšími knihovnami,


8 z 39



► Tento trend můžeme pozorovat i v oblasti vývoje programů ● Na počátku jsme museli navrhovat programy přímo ve strojovém kódu, ● posléze se objevil assembler a různé autokódy ● následované vyššími programovacími jazyky, ● stále rozsáhlejšími a dokonalejšími knihovnami ● a v poslední době i stále dokonalejšími generátory kódu.


9 z 39



► Tento trend můžeme pozorovat i v oblasti vývoje programů ● Na počátku jsme museli navrhovat programy přímo ve strojovém kódu, ● posléze se objevil assembler a různé autokódy ● následované vyššími programovacími jazyky, ● stále rozsáhlejšími a dokonalejšími knihovnami ● a v poslední době i stále dokonalejšími generátory kódu. ► Této automatizaci však stále vzdoruje (a ještě dlouho vzdorovat bude)

návrh architektury programu


10 z 39

1.2 Časté problémy

1/2

► Zkušenost ukazuje, že celkový styl jejich programátora je silně ovlivněn stylem,

který se daný programátor naučil jako první

► Obecně platí: čím rozsáhlejší program jsme vyvinuli, tím je pro nás obtížnější

opustit styl, který jsme si při jeho vývoji osvojili


11 z 39

1.2 Časté problémy – sémantická mezera

2/2

► Kurzy programování na školách se většinou soustředí na kód

a opomíjejí nutnost výuky výrazně jiného způsobu myšlení, namísto OO paradigmatu učí jenom kódování v OO jazyce

● Absolventi těchto kurzů dále vyvíjejí své strukturované programy, jenom je nyní vyvíjejí v objektově orientovaném jazyce ► Výše popsané problémy neplatí to pouze pro změnu paradigmatu,

ale obecně pro libovolnou změnu

► Problémy se tak projevují i v okamžiku, kdy se studenti (a obecně programátoři),

kteří již naprogramovali nějaký středně složitý program, začnou učit navrhovat architekturu systému

► Takto vychovaný programátor myslí a hovoří v termínech kódu;

jakmile obdrží zadání, začne hned přemýšlet, jak by je zakódoval

► Mezi zákazníkem a programátorem vzniká sémantická mezera


12 z 39

1.2.1 Typická situace

1/3

► Zákazník dostane nápad jek zlepšit svůj business


13 z 39


2/3

► Vysvětlí jej programátorovi


14 z 39


3/3

► Který jej geniálně naprogramuje Copyright © Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze 1.00.2413, uloženo po 9.6.2014 – 14:43

15 z 39

1.3 Problém s přecházením na nový styl vysvětluje konstruktivismus ► Problém s obtížným přeučováním na novou látkku

vysvětluje konstruktivistická teorie učení: Student konstruuje své nové znalosti tak, že skládá výklad učitele se svými předchozími znalostmi a zkušenostmi

► Pokud jeho předchozí znalosti a zkušenosti nekorespondují s vykládanou látkou,

tak si v lepším případě podvědomě přednášené informace upraví, aby byly konzistentní s tím, co se doposud naučili; v horším případě je ignoruje

► Důsledek:

Pokud si studenti z přeškolovacích přednášek něco odnesou, bývá to často něco jiného, než se jim přednášející snažil sdělit

► Sebeobrana:

Bát si tohoto nebezpečí vědom(a) a nestydět se ptát, jestli jsem přednášenou látku správně pochopil(a)


16 z 39

1.4 Problémy přiznávají i studenti

1/2

► Řada studentů pokročilých kurzů přiznává problémy

s návrhem architektury rozsáhlejších systémů

● Mívají problémy s návrhem správných objektů, tříd a vzájemných vazeb


17 z 39

1.4 Problémy přiznávají i studenti

2/2

► Řada studentů pokročilých kurzů přiznává problémy

s návrhem architektury rozsáhlejších systémů

● Mívají problémy s návrhem správných objektů, tříd a vzájemných vazeb ► Na vině jsou často

do značené míry učitelé, kteří jsou sami v zajetí svých starých zlozvyků a nedokáží studentům dost jasně vysvětlit nové požadavky ● V řadě případů jenom mechanicky předávají obecně formulovaná pravidla, aniž by poskytly dostatek složitějších příkladů (tj. ne AHA-příkladů), na nichž by aplikaci těchto pravidel demonstrovali


18 z 39

1.5 Správný postup ► Nejprve si ujasníme účastníky, kteří se budou na splnění úkolu podílet ● Při té příležitosti zjistíme, kteří účastníci již existují (jsou např. v knihovně) a které si budeme muset sami vyrobit ► V druhé etapě si ujasníme vlastnosti a jednotlivých účastníků,

přičemž některé jsou již dostupné, jiné jsou teprve požadované ● Během upřesňování vlastností se často objeví potřeba nových účastníků

► V druhé etapě si ujasníme vlastnosti a schopnosti jednotlivých účastníků,

přičemž některé jsou již dostupné, jiné jsou teprve požadované

● Objevíme-li jakýkoliv problém či nedotaženost, můžeme se vrátit k předchozímu nebo dokonce až k prvnímu kroku ● Budeme-li se vyjadřovat dostatečně srozumitelně, dokáže nás zákazník sledovat a případně nás usměrnit, budou-li se naše úvahy ubírat špatným směrem ► Teprve až v následujícím kroku se začneme zabývat tím,

jak zařídit, aby dotváření účastníci uměli přesně to, co od nich požadujeme


19 z 39

2.

Principy metodiky Architecture First

Obsah 2.1 Cíle 2.2 Zásady 2.3 Kurz začíná programováním bez kódování 2.4 Etapy výuky 2.5 Zkušenosti


20 z 39

2.1 Cíle ► Návrh metodiky vychází ze skutečnosti, že v kurzech jsou často namícháni

začátečníci spolu s pokročilými => je třeba definovat takové postupy, které by řešily problémy obou skupin:

► Začátečníci:

Vyžadují co nejsplavnější vstup do tohoto světa, přičemž jim maximálně vyhovuje co největší souvislost a paralela s jejich dosavadními zkušenostmi

► Pokročilí:

Je třeba jim co nejdříve „podříznout větev“ jejich dosavadních zlozvyků a přimět je k tomu, aby se maximálně odpoutali od „kódovacích zvyklostí“ a vrátili se zpět ke způsobu uvažování používanému při řešení problémů běžného života


21 z 39

2.2 Zásady ► Pro dosažení výše uvedených cílů obrací dosavadní zvyklosti


22 z 39

2.2 Pedagogický vzor Ranní ptáče ► Při řazení probíraných témat

se řídí pedagogickým vzorem Ranní ptáče (Early Bird), které říká: „Organizujte svoje kurzy tak, aby se nejdůležitější věci učily jako první. Začněte výkladem klíčových témat a velkých myšlenek. Pokud to není možné, tak alespoň zařaďte jejich výklad co nejdříve“.

_

► Dodržení zásady zabezpečí,

že studenti budou mít dostatek času zažít (a dostat pod kůži) příslušná nejdůležitější pravidla a zásady a naučit se je používat ve svých programech.


23 z 39

2.3 Kurz začíná programováním bez kódování ► Nezačíná se výkladem kódování, ale výkladem architektury ► Na rozdíl od jiných kurzů, které také takto začínají,

se ale tento kurz liší tím, že se od samého začátku vytvářejí chodící programy

► Toho je dosaženo díky použitému vývojovému prostředí BlueJ,

které umožňuje práci v interaktivním režimu, v němž se pouze naznačuje, jak se má program chovat, a vlastní definici navrženého programu dostane na starost generátor kódu, který je součástí použitého vývojového prostředí

► Studenti se tak nemusejí rozptylovat pravidly

syntaxe použitého programovacího jazyka, a mohou se soustředit na návrh architektury vytvářeného programu


24 z 39

2.4 Etapy výuky 1. Úvod do OOP s výkladem základních architektonických principů ● Výklad každého principu je okamžitě následován ukázkou jeho použití při řešení nějakého příkladu ● Úvodní výklad probíhá v interaktivním režimu použitého vývojového prostředí, při němž student pouze ukazuje, co se má udělat (jaké zprávy se mají jednotlivým objektům poslat a v jakém pořadí) a vlastní program (zdrojový kód) vytvoří generátor kódu 2. Opakování látky probrané v první etapě,

přičemž tentokrát se studenti snaží zakódovat programy navržené v první etapě (a definované generátorem kódu)

3. Vysvětlujeme další důležité programové konstrukce,

které jsou však za hranicemi schopností použitého generátoru kódu

4. Výklad algoritmických konstrukcí (podmíněné příkazy, přepínače, cykly …) 5. Vysvětlení dalších důležitých konstrukcí,

pro jejichž realizaci je však zapotřebí znalost algoritmických konstrukcí


25 z 39

2.5 Zkušenosti ► Je až s podivem, jaké aplikace se dají v tomto režimu naprogramovat,

přestože jedinou používanou algoritmickou konstrukcí je sekvence příkazů

► Začínající studenti se v interaktivním režimu mnohem lépe orientují,

protože je nerozptyluje okolní kód

► Obzvlášť dobrá zkušenosti jsou při výuce dětí,

pro něž je řešení problému na architektonické hladině mnohem pochopitelnější, než řešení na hladině kódu, protože je mnohem blíže jejich každodenní praxi

► Nejobtížněji se s tímto režimem vyrovnávají zkušení programátoři,

protože se již odnaučili řešit problémy na této hladině abstrakce

● Připomíná to trochu situaci z počátku 80. let, kdy do kroužků začali přicházet děti se zlozvyky získanými laickým programováním v Basicu, kteří měly problém se zvládnutím příkladů pro robota Karla

§


26 z 39

3.

Výuka v interaktivním režimu

Obsah 3.1 Objekty, třídy, diagram tříd 3.2 Zprávy

3.3.3

Definice testů

3.4 Programové konstrukce demonstrované na testovacích třídách

3.3 Vývoj řízený testy – Test driven development 3.3.1 Testovací třída 3.3.2 Definice testovacího přípravku


27 z 39

3.1 Úvodní seznámení s OOP a BlueJ ► Představíme prostředí BlueJ a projekt používaný v úvodních kapitolách


28 z 39

3.2 Objekty, třídy, diagram tříd ► Každý program je simulací reálného nebo imaginárního světa ► Svět je tvořen objekty => programovací jazyk musí umožňovat pracovat s objekty ► V OOP je objektem vše, co můžeme označit podstatným jménem ● Objektem jsou v OOP i akce a události (výpočet, připojení, přerušení), vlastnosti (barva, směr, krása) a další zdánlivě abstraktní pojmy ► Objekty se stejnými vlastnostmi sdružujeme do tříd

a označujeme je pak jako instance dané třídy

► Třídy jsou také objekty;

v jazycích typu Java, C# apod. jsou to však zvláštní druhy objektů ● Nejsou instancí žádné třídy ● V řadě situací se na ně nemůžeme obracet přímo, ale prostřednictví speciálního zástupce, kterým je instance třídy Class ● Každá třída má svého vlastního zástupce, jenž je současně jediným zástupcem dané třídy

► V BlueJ jsou třídy daného projektu znázorněny jako obdélníky v diagramu tříd,

vytvořené instance v tzv. zásobníku odkazů zastupujícím diagram objektů


29 z 39

3.3 Zprávy ► Objektům můžeme posílat zprávy, přičemž řada jazyků připouští zaslání

pouze takových zpráv, u nichž je předem známo, že jim objekt porozumí

► Pro každou zaslatelnou zprávu je definován kód specifikující,

jak má daný objekt na tuto zprávu reagovat – tento kód označujeme termínem metoda

► V BlueJ zasíláme povolené zprávy zadáním odpovídajícího příkazu

v místní nabídce daného objektu (třídy, instance)

► V místní nabídce každého objektu jsou příkazy zasílající dva druhy zpráv: ● Příkazy v horní části nabídky zasílají zprávy danému objektu ● Příkazy v horní části nabídky zasílají zprávy vývojovému prostředí ► V místní nabídce třídy jsou zprávy zaslatelné třídě rozděleny do dvou skupin: ● Příkazy začínající klíčovým slovem new zasílají zprávy žádající vytvoření objektu ● Ostatní příkazy zasílají standardní zprávy zaslatelné dané třídě ► Zprávu lze poslat i virtuálnímu stroji – rozumí ale jen zprávě, aby se restartoval


30 z 39

3.4 Vývoj řízený testy – Test driven development ► Metodika vývoje řízeného testy doporučuje napsat nejprve testy,

a teprve pak testovaný program

► Pro usnadnění návrhu testů a následného testování byla vyvinuta knihovna JUnit,

podporující návrh a spouštění testů na platformě Java

► Většina vývojových prostředí (mezi nimi i BlueJ) nabízí funkcionalitu

usnadňující používání této knihovny

► Pro testování využívající této knihovny se používají testovací třídy,

které mají některé speciální vlastnosti

► Testovací třída a její testy nabízejí jednoduchou možnost,

jak si zapamatovat posloupnost prováděných akcí a v budoucnu ji v případě potřeby jednoduše zopakovat


31 z 39

3.4.1 Testovací třída ► Testovací třídu můžeme vytvořit dvěma způsoby: ● Stiskem tlačítka Nová třída (New Class) a následným nastavením přepínače Typ třídy (Class Type) na Testovací třída (Unit Test) ● Zadáním příkazu Vytvořit testovací třídu (Create Test Class) v místní nabídce třídy; takto vytvořená testovací třída pak bude vystupovat jako sdružená s příslušnou testovanou třídou ► Přepokládá se, že v testovací třídě je definováno: ● Metoda, která před testem vytvoří tzv. testovací přípravek, což je skupina objektů, které budeme následně testovat ● Jeden nebo více testovacích metod prověřujících přípravek; konkrétní test (instance testovací třídy) ale spustí pouze jednu z nich – která to bude, se definuje při vytvoření dané instance ● Uklízecí metoda, která po provedeném testu uklidí ► Testy probíhají následovně: 1. Vytvoří se test = instance testovací třídy 2. Zavolá se jeho metoda vytvářející testovací přípravek 3. Zavolá se zadaná metoda, která přípravek otestuje 4. Zavolá se metoda, která po testu uklidí Copyright © Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze 1.00.2413, uloženo po 9.6.2014 – 14:43

32 z 39

3.4.2 Definice testovacího přípravku ► Testovací přípravek definujeme tak, že: 1. Restartujeme virtuální stroj (automatický restart se provede při každém překladu) 2. Předvedeme požadovanou akci (zašleme správnému objektu správnou zprávu), resp. posloupnost akcí 3. Zadáním příkazu Dosavadní činnost ►Testovací přípravek (Executed Actions ►Test Fixture) v místní nabídce příslušné testovací třídy požádáme BlueJ o definici metody, která na požádání zopakuje právě předvedenou činnost vytvářející testovací přípravek ► Bude-li mít třída již definovánu metodu vytvářející testovací přípravek,

BlueJ nás při zadání požadavku na vytvoření takové metody na tuto skutečnost upozorní a zeptá se nás, chceme-li exitující metodu nahradit


33 z 39

3.4.3 Definice testů ► Test definujeme tak, že 1. Zadáme příkaz Vytvořit testovací metodu (Create test method) v místní nabídce testovací třídy 2. V následně otevřeném dialogovém okně zadáme název definované metody; bude-li mít třída již definovánu stejnojmennou testovací metodu, BlueJ nás při zadání požadavku na vytvoření takové metody na tuto skutečnost upozorní a zeptá se nás, chceme-li exitující metodu nahradit 3. Po potvrzení se vytvoří testovací přípravek a my můžeme začít předvádět 4. Zasláním správných zpráv správným objektům předvedeme, jak by měl probíhat právě definovaný test 5. Stiskem tlačítka Ukončit (End) na panelu tlačítek ukončíme předvádění testu a vývojové prostředí (přesněji jeho generátor kódu) definuje v dané testovací třídě metodu, která při svém zavolání provede právě předvedený test; Pokud si definici dané testovací metody v průběhu předvádění rozmyslíme, stiskem tlačítka Storno (Cancel) na panelu tlačítek zadávání metody ukončíme a daná metoda se nevytvoří (resp. původní metoda se nepřepíše)


34 z 39

3.5 Návrhové vzory – rozhraní – implementace – interface ► Zadání: definovat metodu, která přesunou objekt do cílové pozice plynule ● Bylo by třeba v několika třídách napsat skoro stejný kód – to je špatně ● Lze jej definovat v separátní třídě, která převezme přesouvaný objekt jako parametr ● Předchozí bod moc nepomohl, protože by metod zůstávalo několik, i když by tentokrát byly ve společné třídě ● Řešení nabízí návrhový vzor Služebník ► Co je to návrhový vzor ► Představení návrhových vzorů použitých v současném projektu ● Knihovní třída (Library Class, Utility) ● Jednoduchá/statická tovární metoda (Simple/Static Factory Method) ● Jedináček (Singleton) ● Výčtový typ (Enum Type, Multiton)


35 z 39

3.5.1 Rozhraní – implementace – interface ► Rozhraní × implementace ► Signatura × kontrakt ► Interfejs (interface) jako programová realizace typu

deklarujícího rozhraní dané skupiny objektů

► Výhody: ● Může definovat společného rodiče více typů, jejichž instance se pak mohou vydávat za instance příslušného rodičovského interfejsu ● Může oddělit instance dvou různých tříd, takže je pak možno je upravovat nezávisle ► Kdy má smysl zahrnout do architektury interface


36 z 39

3.6 Další konstrukce probírané v interaktivním módu ► Definice standardních (ne testovacích) tříd ► Jak definovat třídu, která implementuje zadaný interface ► Návrhový vzor Přepravka (Crate) ► Hodnotové a odkazové objektové datové typy, mutabilita objektů ► Definice implicitních a statických metod v interfejsu ► Balíčky (packages) a jmenné prostory (name spaces) ► Návrhové vzory Stav (State) a Dekorátor (Decorator) ► Začlenění lambda výrazů do návrhu ► Dědičnost implementace, definice potomka ► Definice společného předka, abstraktní třídy ► Návrh složitějších projektů


37 z 39

3.7 Závěrečný příklad ► Závěrečným příkladem realizovaným v interaktivním módu jsou závody automobilů,

při nichž několik účastníků jede po shodných drahách a soutěží, který z nich projede zadanou trať jako první

§


38 z 39

4.

KONEC

Zdroje:


39 z 39

Metodika. Architecture First. Rudolf Pecinovský

Recommend Documents