Programovací techniky

Softwarový projekt

Typy SW projektů (dle zadavatele)

• Zakázkový software

–Zadavatel má nápad a peníze, ale neumí to udělat    najde si realizátora

–Např. ŠIS

–Podtyp: subdodávka komplexního řešení

• Hlavní dodavatel je vůči subdodovatelůmv roli zadavatele

• Software pro volný trh

–Firma vymyslí a vytvoří program, pak se ho snaží prodat (mnoha) zákazníkům

–Např. MS Windows, Adobe Photoshop, …

• Interní projekt

–Firma si pro své vnitřní potřeby vytvoří software (zadavatel a realizátor jsou různá oddělení stejné firmy)

• Jiné typy projektů

–Open source projekty (Linux, Firefox, …)

• Řada projektů je zvláštních: není zde jasný zadavatel (co má program dělat), část práce odvedou dobrovolníci

(zdarma) –často role zadavatele, realizátora i finančního zdroje hraje komunita

My se dále podrobněji podíváme na tvorbu zakázkového software (dobře se na tom ukazují jednotlivé činnosti)

• Tedy jaké činnosti zahrnuje tvorba software?

–(U zakázkového typu)

Zadavatel     realizátor

• Zadavatel musí sdělit, co vlastně chce

• Přenos myšlenky není nikdy dokonalý

–Nevyřčené předpoklady (na obou stranách)

–Špatné pochopení (na obou stranách)

–Neznalosti (na obou stranách)

–Střet dvou světů

• Člověk (vágní) a počítač (přesný)

–Co s tím?

Zadavatel ↔realizátor

• Komunikace musí být obousměrná (↔)

–Aktivně se ptát

• Proč to chcete? Co je cílem?

–Někdy je lepší úplně jiné řešení, než s kterým zadavatel původně přijde

–Vyjasňovat si, ověřovat si

• Nakreslit, ukázat (ukázkové verze co nejdříve –nemusí být plně funkční)

• Např. use cases(případy užití) –jak se program bude používat (scénáře užívání)

• Zápis dohodnutého   formální specifikace

Use case

• Seznam kroků, jak v programu dosáhnout nějakého cíle

–Obvykle kroky popisující interakci mezi uživatelem a programem

• Např. přihlášení na zkoušku v ŠISu:

1. Student vybere akci „přihlášení na zkoušku“.

2. ŠIS vypíše seznam předmětů, které má student v daný semestr zapsané

3. Student vybere, o který předmět mu jde

4. ŠIS vypíše seznam zkouškových a zápočtových termínů daného předmětu (na které se v aktuální okamžik dá přihlásit, tj. jsme v časovém intervalu začátek přihlášení –konec přihlášení)

5. Student si vybere termín a kliknutím na „Přihlásit se“ se na něj přihlásí

6. ŠIS zobrazí potvrzení, že se přihlášení povedlo, a zobrazí seznam všech termínů, na které je student aktuálně přihlášen

Use case: zápis a přínosy

• Zápis use cases:

–Různě (text i diagramy), často se využívá jazyk UML

• Oproti prostému seznamu funkcí programu mají use casesnapříklad tyto přínosy:

–Umožňují programátorům lépe pochopit, jak se dané funkce budou využívat (např. jaký je jejich kontext, jaké je pořadí), a tak vedou k lepšímu návrhu programu (návrh uživatelského rozhraní, volba vhodných datových struktur a algoritmů)

–Obvykle zachycují to nejdůležitější, co má program umět (tj. lépe se stanovují priority)

–Vedou k upřesňování ošidných situací („co má program dělat, když se stane to a to“) –a to už v rané části vývoje (specifikace, návrh, ne až v okamžiku implementace)

Formální specifikace

• Specifikace:

–Funkce programu

•Programátorské rozhraní (API), protokoly, …

–Uživatelské rozhraní programu

–Vlastnosti (rychlost)

–Platforma (HW i SW)

Změna je život

• Připravit se na změny programu

–Proč?

• Změna názoru, nový nápad, změnila se situace (na trhu, legislativa, v podniku, …)

–Počítat s tím v časovém plánu

–Návrh programu udělat (trochu) obecnější

• Aby změny byly snazší

Mám specifikaci, už píšu kód?

• Kdepak, nejdříve musím vybrat…

–Vhodné nástroje, prostředky a lidi

• Platformu (není-li součástí zadání)

• Knihovny(frameworky, toolkity, grafický engine)

–Nemá smysl vše tvořit od nuly, je možné využít už hotová řešení

• Programovací jazyk

• Vývojové prostředí (IDE)

• Lidé (role a počet)

• Metoda vývoje / řízení projektu

Mám specifikaci, už píšu kód?

• Kdepak, nejdříve musím udělat analýzu (rozbor) a poté udělat…

–Návrh (design)

• Celková architektura (moduly, objekty, co bude na serveru, co na klientovi, rozhraní, protokoly …)

• Algoritmy

• Datové struktury

• Uživatelské rozhraní

Mám specifikaci, už píšu kód?

• Kdepak, nejdříve si celý projekt musím naplánovat…

–Čas (termíny)

–Finance

–Organizační (postup, priority)

–Právnízáležitosti (smlouvy, licence)

Testování

• Každý program obsahuje chyby    testování, ověřování, kontrola kvality

–Funkční chyby

–Nemá požadované vlastnosti („je to ošklivé a pomalé“)

–Bezpečnostní chyby

Management

• Funkce manažera*

–Plánování–stanovení cílů, určení variant, určení termínů

–Organizování–stanovení úkolů jednotlivým lidem a určování pravomocí, odpovědnost, organizační struktura

–Vedení–ovlivňování a motivování lidí, usměrňování a odměňování

–Rozhodování–také řízení rizik

–Kontrola–zjišťování odchylek, hledání příčin a způsobů nápravy

• Tím jsme shrnuli předchozích 5 snímků

Program už mi funguje, je hotovo?

• Ani náhodou:

–Dokumentace

• Uživatelská –aby uživatelé věděli, jak produkt nainstalovat a používat

• Programátorská –aby programátor věděl, kam „šáhnout“, když chce něco změnit, opravit nebo vylepšit

• Popř. projektová dokumentace (finance, čas, …) –aby podobné projekty proběhly stejně dobře nebo lépe

–Prodej, distribuce, propagace (u software pro volný trh)

–Nasazení software u zákazníka (deployment), integrace do jeho prostředí

–Podpora

Dokumentace

• Uživatelská

–Aby uživatelé věděli, jak produkt a používat

–Popis instalace(systémové požadavky: HW a SW), představení funkcí programu, vysvětlení ovládání, …

• Programátorská

–Aby programátor věděl, kam „šáhnout“, když chce něco změnit, opravit nebo vylepšit

–Popis struktury programu, složitějších algoritmů, datových struktur, rozhraní, protokolů

• Zahrnuje i komentáře ve zdrojovém kódu

• Projektová

–Aby byl projekt dokončen a aby podobné projekty proběhly stejně dobře nebo lépe

–Co se kdy dohodlo (a popř. i důvody), jak dlouho daná věc trvala, kolik to stálo peněz,

Podpora (SLA)

• SLA(Service-LevelAgreement)

–Dohoda o úrovni poskytovaných služeb

• Hotline, Help desk, Call centrum

–Osobně/telefonicky/e-mail/webový formulář?

–Jen čtvrtek 10:00–16:00, nebo non-stop každý den?

• Školení uživatelů a správců systému

• Oprava chyb

–Jak rychlá reakce na nahlášenou chybu?

• Další rozvoj programu (nové funkce)

–Dohoda o tom:

• jaké služby, jaká úroveň, jak dlouho (30 dní, 1 rok, 5 let, …), za jakou cenu

Fáze tvorby programu(technický pohled)

1.  Zadání (co má dělat)

2.  Algoritmus(postup, jak to má dělat)

3.  Zdrojový kód(text)

4.  Strojový kód(01001001…)

Algoritmus

• Postup řešení dané úlohy

• Například algoritmus sečtení dvou dlouhých celých čísel (487512493 + 9345678):

–Napiš čísla pod sebe (zarovnáno vpravo)

–Postupuj po číslicích zprava doleva:

• Sečti dvě číslice nad sebou

• Je-li výsledek 0 až 9, zapiš výsledek

• Je-li výsledek 10 a více, zapiš poslední číslici a 1 jde dále (do následujícího součtu)

• Pokud číslice chybí (číslo je krátké), domysli si tam 0

Zdrojový kód (source code)

• Text, který:

–Napsán člověkem(většinou)

–Je v programovacím jazyce

–Popisuje chování programu

• Příslušný textový soubor má příponu obvykle podle použitého programovacího jazyka

–*.cpp(C++), *.cs(C#), *.java(Java), *.pas (Pascal), *.php(PHP), *.js(JavaScript), …

Strojový kód (machinecode)

• Binární kód

–Generován (většinou)

–V jazyce stroje (počítače, hardware, procesoru)

• Rozumí mu procesor (CPU)

• Pro různé procesory může být strojový kód jiný

–Posloupnost příkazů (instrukcí) pro počítač

• Binární soubory se strojovým kódem mívají příponu podle zvyklostí daného OS:

–Windows: *.com, *.exe, *.dll

•exe= executable(spustitelný, proveditelný), jde o formát PE (Portable Executable)

–Linux: bez přípony (ale s právem „execute“)

• Jde o formát ELF (Executableand LinkableFormat)

• Zdrojový kód není na počítači (hardware) přímo spustitelný (proveditelný)

–Hardware (procesor) mu nerozumí

• Jak vykonat takový program?

–Interpretace

• Interpret provede ty kroky, které jsou ve zdrojovém kódu uvedeny

–Překlad(kompilace) do strojového kódu

• Překladač (compiler) převede (přeloží) program do podoby strojového kódu dané platformy (procesoru)

Interpretace (interpretation)

• Speciální program, tzv. interpret, vezme jako svůj vstup daný zdrojový kód (text) a provede příslušné akce (které jsou ve zdrojovém kódu uvedeny)

–Daný programovací jazyk se pak často označuje jako skriptovací jazyk(scriptinglanguage)

• PHP, Javascript, Python, batchfile(*.bat), shellscript(*.sh), …

–Interpret je ve formě strojového kódu (např. *.exe)

–Příklady interpretrů:

• JavaScriptengine(součást webových prohlížečů), cmd.exe (pro dávkové soubory *.batna Windows), Bash(pro tzv. shellskripty *.shna Linuxu), php.exe (PHP engine), …

Překlad (compilation)

• Převod z programovacího jazyka (tj. zdrojového kódu) do jazyka stroje (strojového kódu)

–Provádí speciální program: překladač(compiler)

• Musí umět oba jazyky

• Je ve formě strojového kódu (např. *.exe)

• Příklady:

–cl.exe (Microsoft VisualStudio), GCC (GNU CompilerCollection), Intel C++ Compiler(překladač od výrobce procesorů)

–Typické pro tyto jazyky:

• Pascal, C, C++

Překlad do bajtkódu(bytecode)

• Překlad nemusí být vždy až do strojového kódu nějakého procesoru (hardware)

• Překlad může být jen „na půl cesty“, do kódu nějakého pomyslného (virtuálního) procesoru

–Typické pro jazyky Java nebo C#

–Takový kód se označuje jako bajtkód(bytecode) nebo p-code(portable, přenositelný)

• Pro člověka je obvykle nečitelný (jde o binární kód)

• U C# se bajtkódukládá do souborů *.exe, u jazyka Java je to *.class

–Pro běh bajtkóduje nutný speciální program, který chod takového virtuálního procesoru (stroje) simuluje

• Např. Java Runtime Environment(JRE, běhové prostředí Java) nebo CommonLanguageRuntime (CLR, pro C#/.NET)

Překlad do bajtkódu(poznámky)

• Obsah *.exesouboru může být dvojí:

–Strojový kód (přímo spustitelný na procesoru)

–Bajtkód(pro spuštění je třeba CLR, což v praxi znamená mít nainstalován .NET Framework)

• U jazyka Java můžete narazit na dva typy souborů:

–*.java(zdrojový kód = čitelný text)

–*.class(bajtkód, nečitelný, pro spuštění je třeba JRE)

• Popř. ještě *.jar (což je ZIP archiv, kde je „zabaleno“ několik *.classa jiných souborů)

AOT vs. JIT kompilace

• K překladu programu může dojít ve dvou okamžicích:

–Před spuštěním programu (AOT = ahead-of-timecompilation)

• Výsledek překladu je třeba uložit do nějakého souboru (např. *.exe, *.class)

–V okamžiku spuštění/běhu programu (JIT = just-in-timecompilation)

• Výsledek překladu stačí mít v operační paměti (RAM), není nutné nic ukládat do souboru

• Umožňuje různé optimalizace kódu (např. využití možností procesoru, na kterém program právě běží, nebo využití znalosti, která část kódu se jak často využívá) pro zlepšení „kvality“ překladu a tím zvýšení výkonu programu

• Prodlužuje čas potřebný pro spuštění programu

Rozdíly mezi metodami

• Přenositelnost programů

–Strojový kód je nepřenositelný

• Na jiné platformě fungovat nemusí, ať už z důvodu odlišného formátu souboru (PE/ELF), tak z důvodu odlišných možností hardware (procesoru)

–Zdrojový kód a bajtkódjsou přenositelné

• Ale pro svůj běh vyžadují speciální program (interpret nebo virtuální stroj / běhové prostředí)

• Rychlost běhu programu

–Strojový kód je (může být) nejrychlejší

• Může využít všech možností daného hardware (procesoru)

–Bajtkódve virtuálním stroji je pomalejší

• Je zde režie běhu samotného virtuálního stroje

• Kód pro virtuální stroj nemůže využít všech výhod aktuální platformy (virtuální stroj musí být schopen běžet na více platformách, takže může nabízet jen ty vlastnosti, které jsou pro všechny podporované platformy společné)

–Interpretace je (obvykle) nejpomalejší

• Zdrojový kód má strukturu vzdálenější stroji (než bajtkód)

Použití metod

• Pro řadu programovacích jazyků lze použít (se používá) více uvedených metod

–Java: bytecodea dále běh na virtuálním stroji nebo JIT kompilace

–JavaScript: tradičně interpretovaný, ale v nových verzích webových prohlížečů probíhá JIT kompilace

–PHP: tradičně interpretovaný, ale existují i překladače do bytecode(a dále virtuální stroj nebo JIT kompilace)

–Python: bytecodea virtuální stroj (CPython); JIT kompilace (PyPy)

Použití metod: Android

• Android verze 1.0–2.1

–Programátor napsal zdrojový kód v jazyce Java (*.java)

–Ten se běžným překladačem přeložil na bajtkódpro JVM (*.class)

–Ten se programem „dx“ přeložil na bajtkódpro virtuální stroj Dalvik(*.dex= DalvikExecutable)

• Dalvika JVM se liší instrukční sadou, typem stroje (stack/register) atd., Dalvikje optimalizovaný pro mobilní zařízení (potřebuje málo paměti apod.)

• Android verze 2.2–4.4

–Dalvikprovádí JIT kompilaci, aby programy běžely rychleji

• Android verze 5.0 („Lollipop“)

–Dalvikje nahrazen ARTem(ART = Android Runtime)

• ART provádí AOT kompilaci (v okamžiku instalace aplikace), což dále zvyšuje výkon; používá se souborový formát

ELF (jako v Linuxu)

Syntax, nástroje, platforma

Syntax = pravidla zápisu

• Sémantika = význam zápisu

Příklad syntaxe: e-mailová adresa

• RFC 5322 (Internet MessageFormat)

–Addressspecification

• http://tools.ietf.org/html/rfc5322#section-3.4

E-mailová adresa (pravidla)

•E-mailová adresa má 3 části:

–Lokální část (např. název schránky)

• Může obsahovat jen některé znaky

–Určitě lze a–z, 0–9, tečku

–Určitě lze některé další znaky (pomlčku, …) a určitě nelze některé „divné“ znaky (např. s diakritikou)

»To je třeba nastudovat z norem (RFC)

–Určitě nelze mezeru (jinak nepoznám konec adresy)

–Určitě nelze „@“ (jinak nepoznám konec lokální části)

–Znak „@“

–Doménové jméno (serveru)

• Platí obecná pravidla pro zápis doménových jmen

–Viz příslušné normy (RFC)

E-mailová adresa (syntax)

• Popis syntaxe na předchozím snímku je špatně

–Lokální část může obsahovat mezeru i zavináč

–Tečka v lokální části může být jen „uvnitř“ (ne na krajích)

–Je možné použít skoro libovolný znak z Unicode*

• Platné e-mailové adresy: hodne.dlouha.lokalni.cast@dlouha.domena.example.com "martintrcka"@example.com

" "@example.org "martin@vsmiep.cz"@example.com

!#$%&'*+-/=?^_`{}|~@example.org "()<>[]:,;@\\\"!#$%&'*+-/=?^_`{}| ~.a"@example.org üñîçøðé@üñîçøðé.com

* Dle Wikipedie (v RFC 5322 jsem to nenašel, asi to bude v jiné normě). Všechny výše uvedené příklady jsou převzaty (a případně mírně upraveny) z článku http://en.wikipedia.org/w/index.php?title=Email_address&oldid=597633294#Examples5. 3. Kompletní zápis adresy

• Může obsahovat i jméno:

martin.trcka@vsmie.cz

<martin.trcka@vsmie.cz> Trcka<martin.trcka@vsmie.cz>

"Martin Trcka" <martin.trcka@vsmie.cz> "Dwayne\"TheRock\" Johnson" <r@rock.cz>

• Dále může:

–Obsahovat komentář (v kulatých závorkách), být rozdělen na více řádků nebo obsahovat tzv. bílé znaky (whitespace)

• http://tools.ietf.org/html/rfc5322#section-3.2.2

• http://cs.wikipedia.org/wiki/Bílý_znak

–Být zapsán podle zastaralých (obsolete), volnějších pravidel

• http://tools.ietf.org/html/rfc5322#section-4

Syntax vs. sémantika

• Syntakticky správné e-mailové adresy, ale sémanticky špatné:

–x@vsmie.cz

• Schránka s tímto jménem neexistuje

–martin.trcka@x.vsmie.cz

–martin.trcka@vsmiex.cz

–martin.trcka@vsmie.czx

• Ani jedna z uvedených domén neexistuje

• Špatné rodné číslo (i když formát zápisu je v pořádku):

–561332/1234

• Špatná IP adresa (i když formát zápisu je v pořádku):

–192.168.0.315

Dílčí závěry

1. Spousta věcí vypadá jednoduše, ale má-li být popsána přesně, je to složité (viz RFC)

–Počítač (stroj) ale potřebuje přesný popis, který zahrnuje všechny možnosti (i výjimečné)

2. Pro funkční komunikaci dvou programů je důležité, aby byla ustanovena pravidla komunikace

–Protokol (síťový), rozhraní (API), formát (souboru)

3. Kontrola (validace) vstupů od uživatele je těžká

–Programátor může snadno udělat chybu

• Nemalá část bezpečnostních chyb je tohoto typu

–Rada: použít knihovny, kde už je toto naprogramované

4. Samotná kontrola syntaxe nemusí stačit

–Někdy může být nutná i kontrola „významu“

Syntaktická analýza (parsing)

Syntaxe vs. sémantika(C#)

Syntakticky je program v pořádku, ale proměnná „pocet“ není nikde použita.

Syntakticky je program v pořádku, ale proměnná „vtup“ (překlep) neexistuje.

NÁSTROJE

IDE

•Integrateddevelopmentenvironment(IDE)= integrované* prostředí pro vývoj (software)

• Může zahrnovat:

–Editor kódu (zvýrazňování syntaxe aj.)

• Prohlížeč objektů, prohlížeč hierarchie tříd, …

–Překladač / interpret

• Nástroje pro řízení překladu (různé platformy atd.)

–Nástroje pro ladění (debugger)

–Nástroje pro návrh GUI, testování, …

• Příklady pokročilých funkcí viz např. http://www.microsoft.com/visualstudio/cze/products/compare#feature-chart- heading

* Integrovaný = tvořící vzájemně propojený funkční celek

IDE (příklady)

• VisualStudio (Microsoft)

• Eclipse

• IntelliJIDEA

• NetBeans

• JDeveloper(Oracle)

• Starší:

–Turbo Pascal, Delphi, C++Builder(Borland), …

Editor kódu

• Zvýrazňování syntaxe

• Doplňování kódu

• Propojení s nápovědou

–F1 zobrazí nápovědu dle kontextu (pozice kurzoru)

• Dále:

–Operace ve více souborech najednou

–Pokročilé vyhledávání (např. regulární výrazy)

–Refactoringkódu

Zvýrazňování syntaxe(syntax highlighting)

Různé syntaktické prvky (proměnné, klíčová slova, textové řetězce atd.) mají různý vzhled, typicky různou barvu písma.

Doplňování kódu(codecompletition)

Napovídání názvů proměnných, funkcí, metod atd. podle kontextu (souvislostí), popř. včetně vysvětlivek. Regulární výrazy(regularexpressions)

• Speciální „vzory“ (zápisy) pro vyhledávání složitějších textových výrazů

–Existují různé jazyky pro zápis regulárních výrazů (POSIXové/Unixovéregulární výrazy, Perlovskéregulární výrazy, …)

• Příklady:

Regulární výraz                                                                      Vyhledá

Agent 00[1-7]                                                                                                   Agent 001, Agent 002, …, Agent 007

Colou?r                                                                                                               Color, Colour

Hurá+                                                                                     Hurá, Huráá, Hurááá, Huráááá,…

([A-Z]):\1                                                                                                          A:A,B:B, C:C, D:D, E:E, …

Návrh GUI

Debugger

• Nástroj (program) pro hledání chyb vprogramech (bug= chyba)

–Podrobněji na příští přednášce

IDE není vše

• Pro práci (zejména) v týmu se hodí nástroje pro:

–Řízení týmových projektů

• Plánování (dle různých metodik), správa členů projektu, sledování průběhu, vykazování,

• Komunikace členů týmu (text, hlas, video)

–Sdílení a správu verzí (zdrojových kódů aj.)

–Správu sestavení (build)

–Správu testování

–Správa dokumentace (generování částí dokumentace)

–Modelování, diagnostiku, nasazení/publikování, …

• Příklad komplexnějšího nástroje:

–Team FoundationServer (Microsoft)

• http://www.visualstudio.com/cs-cz/products/tfs-overview-vs#Fragment_ProductFeatures

Správa verzí(versioncontrol, revisioncontrol)

• Správa změn ve zdrojových kódech programu

–Popř. i v dokumentaci, konfiguračních souborech, datových zdrojích atd.

• Příklady výhod:

–Řízení přístupu více programátorů k jednomu kódu

–Možnost návratu ke starší verzi kódu

• Např. „ještě včera to fungovalo“

–Možnost souběžného vývoje dvou (více) verzí programu

• Např. ve „stabilní“ verzi se opravují chyby, zatímco ve „vývojové“ verzi už se zkoušejí nové funkce

• Příklady specializovaných programů:

–CVS (ConcurrentVersionsSystem), Subversion(svn), Git, Mercurial, Microsoft VisualSourceSafe, …

Generování dokumentace

• Nástroje, které z komentářů ve zdrojovém kódu umí vygenerovat (část) dokumentace

–Dokumentační komentáře musí dodržovat určitá pravidla zápisu (aby se odlišily od běžných komentářů)

–Výsledná dokumentace může být provázána hypertextovými odkazy (formát HTML)

–Příklady: Javadoc(Java), Doxygen(C++, Java, PHP, Python, …)

• Příklad zdrojového kódu s dokumentačními komentáři:

–http://www.docjar.net/html/api/java/util/Collections.java.html

• Příklad vygenerované dokumentace:

–http://docs.oracle.com/javase/7/docs/api/

• Vlevo nahoře klikněte na java.utila pak vlevo dole v části Classesna Collections:vpravo bude odpovídající

dokumentace

PLATFORMA

Platforma (počítačová)

• Souhrn prostředků (HW i SW), které slouží jako „základna“ pro běh programů

• Může zahrnovat:

–Hardware, zejména procesor

• Jakou instrukční sadu používá

–Operační systém

• Které funkce, resp. systémové knihovny program vyžaduje

–Aplikační prostředí

• Např. framework, který program využívá

Platforma (dle procesoru)

• IA-32 (Intel Architecture, 32-bit), též x86

–Pojmenování „x86“ vychází z označení prvních Intel procesorů této architektury: 80286, 80386, 80486

–Nejen Intel, ale i AMD, VIA Technologies nebo Transmeta

• IA-64 (Intel Architecture, 64-bit)

–Intel Itanium(od roku 2001), hlavně servery

• Podporuje např. Windows XP 64-bit Edition

• x86-64, též x64, AMD64, Intel 64

–64bitové rozšíření instrukční sady IA-32

–Většina dnešních „běžných“ počítačů

• Architektura ARM (mobilní telefony, televize, …)

• Herní konzole (Playstation, Xbox, Wii, …)

• PowerPC(Apple Macintosh do roku 2006, nyní už x86)

• Speciální počítače (mainframe, superpočítače, …)

Platforma (hardware)

• Nejen instrukční sada procesoru, ale i:

–Výkon procesoru / grafické karty

–Množství dostupné paměti (RAM, HDD)

–Možnosti výstupních zařízení

• Rozlišení a poměr stran displeje, max. počet barev

–Možnosti vstupních zařízení

• Klávesnice / dotykový displej / hardwarová tlačítka / polohovací zařízení (myš, touchpad, Kinect, …)

• U různých stolních počítačů můžou být tyto charakteristiky podobné, ale u herních zařízení (konzolí) a přenosných zařízení (chytrých telefonů, tabletů) už je situace značně odlišná

Platforma (operační systém)

• Windows (Microsoft)

• Mac OS (Apple)

• Linux, FreeBSD, …

• Unix, Solaris, OS/2, AmigaOS, …

• Mobilní telefony:

–Android (Google)

–iOS(Apple)

–Windows Phone(Microsoft)

–BlackBerryOS

–Symbian(Nokia)

Framework (software)

• Knihovna funkcí, které tvoří základ pro vývoj software

–Obvykle obecné funkce, často i obecná „kostra“ programu –funkce specifické pro cílovou aplikaci nutno

doprogramovat

• Příklady frameworkůpro tvorbu webových aplikací:

–jQuery(Javascript), NetteFramework (PHP), ZendFramework (PHP), Ruby on Rails, ASP.NET MVC Framework, Spring(Java), Django(Python)

Platforma (aplikační prostředí)

• .NET Framework (Microsoft), Mono (open sourceimplementace)

• Java platform

• Adobe Flash, Adobe Shockware, Adobe AIR

• Silverlight(Microsoft)

• Qt, GTK (tvorba GUI)

Chyby

Co je to chyba?

• Dva pohledy:

–Programátor: co je v rozporu se specifikací programu

–Uživatel: co funguje jinak, než by chtěl

• Ideální by bylo mít tyto pohledy v souladu (tj. aby specifikace zachycovala to, co uživatel chce)

–Ale ne vždy se to podaří

• Může dojít i k hádkám o to, zda dané chování programu je chyba, nebo ne (tedy kdo zaplatí opravu)

Běžné příčiny chyb

• Člověk(aneb každý dělá chyby)

–Co zvyšuje míru chyb?

• Nedostatečná kvalifikace a/nebo zkušenost

• Časový tlak (honí se termín)

• Únava (přepracování)

• Špatné pracovní prostředí (vyrušování, nepohodlná židle, velká teplota v místnosti, nedostatek tekutin, špatné osvětlení, …)

• Malá motivace (např. nezáleží mu na kvalitě)

• Mimopracovní (např. rodinné) problémy

• Komunikace (mezilidská)

–Zadavatel ↔ realizátor

–Vedoucí týmu ↔ programátor

Špatná analýza požadavků

–Podcenění složitosti projektu

• Z toho plynoucí časový tlak, přepracování, …

–Nedostatky v zadání

• Aplikace je perfektní (dle zadání), ale skuteční uživatelé chtěli (potřebovali) něco jiného

• Nové technologie

–Nevyzkoušené funkce nebo celé knihovny

• Chvíli trvá, než se programátor s novou technologií seznámí a než ji umí správně použít

• Nové projekty obsahují větší míru chyb (tvůrce se v prvotních fázích soustředí na funkce, projekt není otestován na velkém vzorku uživatelů), dokumentace může být nedostatečná, …

Běžné typy chyb (technicky)

• Aritmetické chyby

• Logické chyby

• Jazykové omyly

• Chybná práce s pamětí

–Přetečení zásobníku, únik paměti

• Chyby souběžných systémů

–Deadlock, racecondition

• Další chyby

–Výkon, rozhraní, tým

Aritmetické chyby

• Dělení nulou

• Přetečení (overflow)

–intx = 300000; // Int32inty = x * x; // y je −194313216;

• Zaokrouhlovací chyby

–double x = 0.1; double y = (0.1 + 10) -10;Console.Write(x == y); // False

Logické chyby

• Chyba „plus/minus 1“

–Příklad:Mějme čísla 7, 8, 9, …, 22, kolik těch čísel je?22 − 7 = 15?Kdepak, je jich 22 − 7 + 1 = 16.

• Nekonečný cyklus

–// v cyklu zapomeneme zvýšit// proměnnou i o jednainti = 1;while(i != count){………}

• Nebo omylem nastavíme countna záporné číslo

• Operátor !=znamená nerovnost (opak ==)

• Nekonečná rekurze

Jazykový omyl

• if(x = 5) …

–Neprovede test, zda je hodnota proměnné xrovná 5 (to by v závorce muselo být x == 5), ale provede přiřazení hodnoty 5 do proměnné x

Chybná práce s pamětí

• Častá u jazyků, které umožňují přímou práci s pamětí (např. jazyky C, C++)

• Přetečení zásobníku (bufferoverflow)

–Program požádá operační systém o 16 bajtů paměti.Omylem do paměti zapíše 17 bajtů.Zápis posledního bajtu může způsobit:

• Chybu v přístupu do paměti (porušení přístupových práv), což typicky znamená pád programu

• Přepis tam uložené hodnoty (např. proměnné), což může vyústit vprakticky cokoli (divné chování programu, pád programu, …)

–Pokud jsou zapisovaná data (17 bajtů) pod kontrolou uživatele (jde např. o zadávaný vstup), pak lze často tuto chybu využít k narušení bezpečnosti daného programu

Chybná práce s pamětí

• Únik paměti (memoryleak)

–Program požádá OS o 1 MB paměti.Později program tuto paměť přestane využívat, ale zapomene ji „vrátit“.

• Pokud program takto žádá o paměť (a nevrací ji) opakovaně, pak program zabírá v operační paměti stále více a více místa… (až místo dojde)

Příklad: Mozilla Firefoxverze 15 (z 28. 8. 2012) obsahuje funkci, která zmírňuje dopady úniků paměti zásuvných modulů (plug-inů). Vývojáři Firefoxutotiž zjistili, že úniky paměti způsobují z velké části právě zásuvné moduly (tj. cizí programy), ne samotný Firefox. Podrobnosti viz http://blog.mozilla.org/nnethercote/2012/07/19/firefox-15-plugs-the- add-on-leaks/

Chyby souběžných systémů

• Chyby, ke kterým může dojít v případě, kdy běží více programů (popř. vláken*) najednou

–Víceprocesorové počítače (multiprocessing)

–Víceúlohovéoperační systémy (multitasking)

–Vícevláknovéprogramy (multithreading)

–Distribuované systémy

• Programy běží na různých počítačích, ale používají společné zdroje (zejména paměť)

• Příklady chyb:

–Dead-lock(uváznutí)

–Racecondition(souběh)

• Řešení:

–Synchronizace (koordinace běhu)

*  Vlákno (thread) je část programu (tj. posloupnost instrukcí), která může běžet samostatně

Deadlock, racecondition

• Deadlock(uváznutí)

–Program A čeká, až program B dokončí nějakou akci. Zároveň ale program B čeká na dokončení akce programu A

• Takto může čekat i více programů

–Výsledek: Všechny programy „zamrznou“

• Racecondition(souběh)

–Chyba, kdy výsledky závisí na načasování jednotlivých instrukcí programu

–Typický výsledek: někdy se stane něco jiného, než co programátor očekává Racecondition(příklad)

• Program zvyšující čítač X:

–Načti X (z databáze, ze souboru, z paměti)X = X+ 1Ulož X

• Při vícenásobném souběžném použití (spuštění) programu ale může nastat tato situace:

–Kód byl proveden 2×

–Ale čítač byl zvýšen jen 1×

Další chyby

• Chyby ve výkonu programu

–Nadměrné využití procesoru nebo paměti

• Závisí na zvolených datových strukturách a algoritmech

• Chyby při použití rozhraní

–Nesprávné použití API

–Nesprávná implementace síťového protokolu

• Chyby související s prací v týmu

–Např. nesprávné informace (komentáře v kódu, dokumentace, popis API)

• Zastaralé, nekompletní nebo zavádějící informace

Formální analýza kódu

• Nápad: Co udělat program Tester, který zkontroluje můj program (např. jeho zdrojový kód), zda je v pořádku?

• Problémy:

–U netriviálních programů existuje velké množství různých vstupů (a velké množství „průchodů“ programem) kontrola všech možností by zabrala hrozně moc času (miliardu let?)

–Program Tester, který by zkontroloval správnost výsledku, obecně nelze vytvořit

• Nelze totiž vytvořit ani jednodušší program –takový, který zjistí, jestli vůbec můj program vydá nějaký výsledek, tj. jestli můj program vůbec skončí (jde o tzv. problém zastavení)

Problém zastavení (haltingproblem)

• Lze udělat obecný program Tester, který rozhodne, zda se program P se vstupem V zastaví (nebo zda poběží donekonečna)?

–Vstupy: P (kód programu), V (vstupy programu P)

–Výstup: „Ano“ (program P se na vstupu V zastaví), nebo „Ne“ (nezastaví)

• Alan Turing(1936): Ne

–Tedy ani tak jednoduchý problém nelze vyřešit (označuje se za nerozhodnutelný)

• Jinými slovy: zacyklení programu není algoritmicky detekovatelné (a to ani v případě, že známe všechny vstupy

programu)

Reprezentace (odbočka)

• Základní myšlenka: Vše v počítači můžeme považovat za číslo

–Vše má v počítači binární reprezentaci, což je v podstatě jen zápis čísla (i když někdy obrovského čísla, s mnoha a

mnoha ciframi)

• Např. text tvořený 8 znaky je (při použití 1bajtového kódování znaků) vlastně 8bajtové číslo

• Např. rastrový obrázek tvořený 4 ×4 = 16 pixely je (při barevné hloubce 3 bajty) vlastně 48bajtové číslo

–Tedyvšechny vstupy(parametry) programu, výstupyprogramu i programsamotný (ať už zdrojový kód, tj. text, nebo binární kód) jsou jedna a tatáž věc, číslo (liší se jen hodnotou)

Problém zastavení (důkaz 1/3)

• Důkaz sporem:

–Předpokládám opak a dojdu k nesmyslnému výsledku (ke sporu)

• Tedy nechť program Testerexistuje

–Tester(X, V) tedy vrátí „Ano“, když program X se vstupem V skončí (jinak vrátí „Ne“)

Problém zastavení (důkaz 2/3)

• Vyrobím program AntiTesters jediným vstupem X

–Program AntiTesterbude fungovat takto:

• Spustí program Tester(X, X)a dále:

–Když je návratová hodnota „Ano“ (= program X se vstupem X skončí), tak se program AntiTesterúmyslně zacyklí (neskončí)

–Když je návratová hodnota „Ne“ (= program X se vstupem X neskončí), tak program AntiTesterskončí (s libovolnou návratovou hodnotou)

Problém zastavení (důkaz 3/3)

• Co se ale stane, když spustím program AntiTesterse vstupem AntiTester?

–Může buď skončit, nebo neskončit (zacyklit se)

a) Když AntiTesterskončí, tak dle definice AntiTesterumuselo dojít k situaci, že volání Tester(AntiTester, AntiTester)vrátilo „Ne“, což ale znamená (dle definice programu Tester), že program AntiTestersparametrem AntiTesterneskončí, tedy spor s předpokladem a)

b) Když AntiTesterneskončí, tak dle definice AntiTesterumuselo dojít k situaci, že volání Tester(AntiTester, AntiTester)vrátilo „Ano“, což ale znamená (dle definice programu Tester), že program AntiTestersparametrem AntiTesterskončí, tedy spor s předpokladem b)

–V obou případech jsme došli ke sporu, tedy náš předpoklad (že program Testerexistuje) musel být mylný

Jak chyby odhalovat? (1/2)

• Překladač

–Odhalí syntaktické chyby

–Odhalí některé sémantické chyby (nepoužitá proměnná apod.)

• Tracing(logging)

–Výpisy (na obrazovku, do souboru), které informují o stavu programu

• Post-mortemdebugging(„po smrti“)

–Při „pádu“ programu může operační systém uložit obsah paměti programu (v okamžiku pádu) do souboru (dumpfile,

crashdump)

• Lze později obsah souboru analyzovat: zjistit stav programu (hodnoty proměnných, na kterém příkazu program zhavaroval, s jakými parametry byla daná funkce volána atd.) v okamžiku pádu

• Krokování, breakpoint(viz dále)

Jak chyby odhalovat? (2/2)

• Defenzivní programování(„obranné“)

–Programování dle hesla „nevěř nikomu“ (ani sobě

–Např. důsledná kontrola všech vstupních hodnot funkce

• Často se využívá assertions(viz dále)

• Testování

–Spustím výslednou aplikaci a zkouším všechny funkce, různé divné vstupy atd. a sleduji, zda se program nechová nestandardně (špatné výsledky, spadne atd.)

–Napíšu si program, který testování udělá za mě (lze volat různé funkce programu s různými parametry, lze

„naskriptovat“ i klikání v GUI)

• Napsané testy lze hromadně spouštět po každé změně kódu a kontrolovat tak, zda změna něco „nerozbila“

• Unit testing= testování nezávislých částí (jednotek) programu (kódu)

Assertion

• Výraz typu ano/ne, kterým programátor vyjadřuje své očekávání (předpoklad)

–Pokud výraz neplatí, je program ukončen

• Příklad použití:

Pozor: Assertionneslouží pro zvládnutí „chyb“ uživatele programu, když např. uživatel zadá „divný“ vstup –na chyby uživatele totiž neumí assertionnijak rozumně reagovat (nemá žádné tělo). Assertionslouží pro odhalování chyb programátora, např. nesprávné volání funkce, neohlídání si určité krajní situace apod.

Krokování, breakpoint

• Krokování

–Provádění programu krok po kroku (příkaz po příkazu)

• Lze si prohlédnout stav programu (např. hodnoty proměnných) v daném okamžiku

• Breakpoint

–Místo (point) v kódu programu, kde se má běh programu zastavit (break)

• Lze dále provádění programu krokovat

Co s nalezenou chybou udělat?

• Co je to za divná otázka, existují snad důvody, proč nalezenou chybu neopravit?

• Ano, existují:

–Oprava chyby může do programu zavléct jinou, mnohem závažnější chybu

• Např. vyřeším špatné zobrazování ikony, ale program začne padat

–Oprava chyby stojí čas a programátory (tj. peníze)

• A taky s vydáním Windows 95 nelze čekat až do roku 1997

„Bug bar“ (laťka pro chyby)

• Příklad:

–Na začátku projektu je laťka na nule:

• Opravují se všechny chyby, které jsou nahlášeny

–Termín odevzdání projektu se blíží, takže „zvedáme laťku“:

• Opravují se jen chyby, které způsobují ztrátu dat uživatele (nebo horší)

–Termín se ještě více blíží, takže „zvedáme laťku“:

• Opravují se jen chyby, které znamenají smrt člověka* –Termín už je za dveřmi, takže „zvedáme laťku“:

• Opravují se jen chyby, které znamenají smrt blonďatých modrookých holčiček**

*  V řadě oblastí (lékařství, vojenství, fyzikální nebo chemické pokusy, řízení strojů atd.) se tohle skutečně může stát

** Tohle už je vtip

Program s chybami

• Je tedy zcela běžné, že firma vydá program, který obsahuje chyby, o kterých firma ví –Mělo by ale jít o méně závažné chyby

• Uživatel se často smíří s pár menšími chybami, pokud má program pro něj znatelný přínos

Například program Microsoft Word má v některých situacích problémy svykreslováním dokumentu (např. některé řádky jsou vidět „dvojmo“), ale stačí posuvníkempohnout nahoru a dolů a chyba je pryč. Jde tedy o malou chybu a obecně má pro mě tento program velký přínos, takže jsem ve výsledku spokojen.

Bug (issue) trackingsystem

• Aplikace pro evidenci chyb (požadavků*) –Zadávání chyb

• Prostředek pro komunikaci mezi zákazníky (zadavateli chyb), vývojáři (programátory), vedoucími projektů, … –Sledování stavu chyb

• Přiřazování chyb vývojářům, sledování počtu chyb, nastavování priority chyb, přístupová práva k popisům chyb (bezpečnostní chyby)

• Příklady:

–Bugzilla, Mantis, …

*  Požadavky jsou i návrhy na vylepšení, nejen chyby

Jak hlásit chyby?

• Co má obsahovat popis chyby?

• Odpověď získáme, když se zeptáme: K čemu se popis chyby použije?

–Typicky se programátor bude snažit podle toho popisu chybu znovu vyvolat –aby ji mohl prozkoumat

Jak hlásit chyby?

• Popis chyby by tedy měl obsahovat:

–Popis situace popř. aktivity tak, aby bylo možné chybu znovu vyvolat (zreprodukovat)

• Typicky kroky, které k chybě vedou

• Okolnosti (použitý program, platforma atd.)

–Např. řada uživatelů Windows zapomene zmínit, že používají Windows (když chyba může být závislá na operačním systému)

–Popis, jak by to mělo být správně

• Ne vždy je jasné, co přesně uživateli na popsané situaci vadí, nebo jakou změnu udělat, aby to už uživateli nevadilo.

Programovací paradigma

Historie programovacích jazyků(pro základní přehled)Éra      Jazyky vzniklé v dané éře

50.a 60. léta                                                                          FORTRAN, LISP, COBOL, ALGOL,BASIC

1968-1979                                                                                                      Simula(OOP), Logo, Pascal

C(DennisRitchie, KenThompson) Smalltalk, Prolog, Scheme

80. léta                                                                                 C++, Objective-C

Eiffel, Erlang, Perl

90.  léta                                                                                 Haskell, Python, VisualBasic, Ruby, Lua

Java, Delphi(ObjectPascal)

JavaScript, PHP

2000 a později                                                                        ActionScript(FlashPlayer), C#, Clojure,Dart

Úroveň programovacího jazyka

• Nižší (nízkoúrovňový, low-level, strojově orientovaný) jazyk

–Žádná nebo malá míra abstrakce od hardware (procesoru), tj. těsně spjatý s hardware

• Překlad do strojového kódu typu 1 : 1 (jeden příkaz jazyka odpovídá jedné strojové instrukci)

–Např. strojový kód, assembler

• Vyšší (vysokoúrovňový, high-level) jazyk

–Vyšší míra abstrakce

• Překlad typu 1 : N (jeden příkaz odpovídá více instrukcím)

–Např. vše ostatní

Nižší vs. vyšší (+/−)

• Výhody nižších jazyků:

–V některých situacích (jednoduché čipy, robůtci atd.) jediná možnost programování

• Není-li dostupný překladač/interpret

–Větší výkon programu

• Nižší nebo žádná režie (žádné zbytečné instrukce) –Větší kontrola nad tím, co program dělá

• Výhody vyšších jazyků:

–Jednodušší (tj. levnější) tvorba programů

• Jazyky obsahují prostředky usnadňující programování: proměnné, datové struktury, řídící struktury, metody, objekty,

–Lepší přenositelnost programů

• Funkčnost programů na širší skupině hardware