Metodika. Architecture First. Rudolf Pecinovský

Transkript

1 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 1 z 39 Metodika Architecture First Rudolf Pecinovský rudolf@pecinovsky.cz

2 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 2 z 39 Obsah 1. Kapitola 2. KONEC

3 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 3 z Motivace Obsah 1.1 Vývoj IT podpory našich činností 1.2 Časté problémy 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

4 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 4 z 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í

5 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 5 z 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í Tento trend můžeme pozorovat i v oblasti vývoje programů

6 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 6 z 39 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í 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

7 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 7 z 39 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í 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,

8 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 8 z 39 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í 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,

9 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 9 z 39 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í 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.

10 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 10 z 39 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í 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

11 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 11 z Č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

12 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 12 z Č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

13 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 13 z Typická situace 1/3 Zákazník dostane nápad jek zlepšit svůj business

14 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 14 z Typická situace 2/3 Vysvětlí jej programátorovi

15 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 15 z Typická situace 3/3 Který jej geniálně naprogramuje

16 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 16 z 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)

17 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 17 z 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

18 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 18 z 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

19 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 19 z 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

20 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 20 z 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

21 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 21 z 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

22 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 22 z Zásady Pro dosažení výše uvedených cílů obrací dosavadní zvyklosti

23 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 23 z 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. _

24 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 24 z 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

25 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 25 z 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í

26 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 26 z 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

27 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 27 z Výuka v interaktivním režimu Obsah 3.1 Objekty, třídy, diagram tříd 3.2 Zprávy 3.3 Vývoj řízený testy Test driven development Testovací třída Definice testovacího přípravku Definice testů 3.4 Programové konstrukce demonstrované na testovacích třídách

28 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 28 z Úvodní seznámení s OOP a BlueJ Představíme prostředí BlueJ a projekt používaný v úvodních kapitolách

29 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 29 z 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ů

30 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 30 z 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

31 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 31 z 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

32 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 32 z 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í

33 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 33 z 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

34 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 34 z 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)

35 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 35 z 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)

36 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 36 z 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

37 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 37 z 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ů

38 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 38 z 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í

39 Copyright Rudolf Pecinovský, Soubor: 2014_Comm_PrW_Architecture First Methodology.doc, verze , uloženo po :43 39 z KONEC Zdroje: