Pavel Cagaš (pc@mii.cz) Jak se dělá software FIT VUT Brno 14. 5. 2002 Pavel Cagaš (pc@mii.cz) Moravské přístroje a.s.

Prezentace na téma: "Pavel Cagaš (pc@mii.cz) Jak se dělá software FIT VUT Brno 14. 5. 2002 Pavel Cagaš (pc@mii.cz) Moravské přístroje a.s."— Transkript prezentace:

1 Pavel Cagaš (pc@mii.cz)
Jak se dělá software FIT VUT Brno Pavel Cagaš Moravské přístroje a.s.

2 Kapitola 1: Jak se dělá Control Web
Co vlastně děláme?

3 Co vlastně děláme? Programové systémy pro rychlý vývoj aplikací v oblasti vizualizace a řízení technologických procesů: Analýza“ Návrh funkčnosti (architektury) systému. Návrh uživatelského rozhraní. Interoperabilita (COM/ActiveX, SQL/ODBC, HTTP, OPC, …). Kódování a ladění. Testování: Základní funkčnost. Použitelnost, přehlednost, ovladatelnost. Dlouhodobá stabilita, paměťová stabilita. Testovací aplikace. Obcházení chyb Win32 API.

4 Co vlastně děláme? (pokračování)
Údržba jazykových mutací, spolupráce s partnery: Čeština a angličtina v průběhu vývoje. Japonština (UNICODE, Win32 IME). Němčina. Instalace a distribuční systém: Instalační CD-ROM. Prodej přes WWW. Systém licencí a registrace. Dokumentace: Asi 1000 stran základní dokumentace. Ukázkové aplikace, tipy a příklady.

5 Co vlastně děláme? (pokračování)
Školení a technická podpora: Telefonická, podpora. Školení začátečníci/pokročilí, nové verze produktů. Údržba stávajících verzí (Service Packs): Testování kompatibility. Podpora průmyslového HW: Ovladače pro PLC, I/O, standardní sběrnice. Podpora ovladačů třetích stran. Marketing: WWW prezentace. Propagační materiály, prospekty. Inzeráty, PR články. Veletrhy, výstavy a prezentace.

6 Trocha statistiky Prakticky veškerý kód je psán v jazyce Modula-2.
(spíše Modula-2++ ) 12 MB DLL a EXE modulů (optimalizovaný kód). 22 MB binárního neoptimalizovaného kódu. 752 .DEF souborů, 11 MB textu. 695 .MOD souborů, 40 MB textu. 1696 ikon, 12 MB dat. 205 binárních souborů, 3 MB dat. 218 make souborů, 0,5 MB textu. 223 resource skriptů, 0,4 MB textu.

7 Statistika pokračuje Zdrojové kódy (*.DEF, *.MOD) mají řádků textu. V kódu je implementováno tříd (classes). Počet procedur a metod je (Statistika systému CW verze 5 k začátku května 2002)

8 Zdrojové kódy a binární verze
Z jedné sady zdrojových textů se generuje řada binárních verzí: Vývojová a runtime verze, Cluster Server verze, … ANSI a UNICODE verze. Různé jazykové mutace. Verze pro „desktopová“ Windows a Windows CE. Windows CE verze pro různé platformy (CEPC, PocketPC, H/PC, …). Windows CE verze pro různé procesory (x86, ARM, MIPS, SH3/4 …). Build jedné verze systému trvá asi 50 minut. (AMD Athlon 1,2 GHz, 256 MB DDR266 paměti)

9 Výjimečnost software Předešlá čísla nezahrnují historické verze systému pro Extended DOS (Control Panel) a „odumřelé“ vývojové větve, které byly opuštěny nebo nahrazeny novým kódem. Množství kódu (ale i dokumentace, aplikací, …), které nám „prošlo rukama“ je tak výrazně větší. Jak je možné tento objem práce vykonat v relativně malém týmu? Vývoj software má oproti jiným produktům řadu výjimečných atributů. Pokusím se je zobecnit ve druhé části přednášky.

10 Jak vypadá Control Web uvnitř?
Veškerý kód v jazyce Modula-2. Nutná rozšíření standardní definice jazyka vzhledem k jazykově závislé povaze Win32 API (zřejmě se programátorům obtížně brání použití např. výčtů s určeným ordinálním číslem apod.). Control Web vychází z architektury svého předchůdce, systému Control Panel, který pracoval nad systémem DOS.

11 Stručně o Control Panel
Systém Control Panel vznikal v první polovině 90. let (minulého století ). Procesory 486 byly revoluční novinkou, 386 vzácností a 286 ve velmi solidních PC. MS Windows ve verzi 3.0 byly krásnou hračkou do kanceláří, ale pro průmyslové použití téměř nepoužitelnou. Proto Control Panel implementoval řadu vlastností operačního systému, ze systému DOS se jen spouštěl.

12 Control Panel OS Jádro chráněného módu procesorů 286:
16-bitový režim, bez limitu 640 KB systému DOS. Segmentace paměti po 64KB velkých segmentech (x86). Ochrana paměti na úrovni segmentů. Virtualizace paměti, možnost relokace segmentů ve fyzické paměti. Odkládací soubor pro datové segmenty (kódové segmenty zaváděny z původních EXE a DLL). Podpora DLL (dynamicky linkovaný kód). Duální obsluha přerušení (real mode/protected mode). Tunelování požadavků na souborový systém do reálného módu systému DOS.

13 Control Panel OS (pokračování)
Aplikační objektově-orientované API: Grafika nezávislá na zařízení: Ovladače grafiky jako dynamicky linkované binární moduly. Grafická primitiva v systému. Bitmapové fonty pro obrazovku i tiskárny. Systém oken, dialogů, GUI prvků. Událostní subsystém: Poziční, selektované a „broadcast“ šíření událostí. Časovače a „Event Idle“ události.

14 Control Panel OS (pokračování)
Abstraktní objektový dokumentový model DataView: DataView coby abstraktní kontejner na data. Mechanismy správy životního cyklu DataView. Podpora drag-and-drop, zabudovávání, editace na místě. Obecný kontejner pro DataView. Standardní sada uživatelských nástrojů: Nastavení vlastností, barev a metrik GUI. Volby rozložení klávesnice. Nastavení vlastností myši, volby kursorů. …

15 Architektura systému Control Panel
Uvnitř objektově-orientovaný návrh. Navenek komponentová architektura. Malé jádro systému zajišťující: Alokaci komponent „virtuálních přístrojů“ tvořících aplikaci. Alokaci I/O ovladačů. Komunikace mezi přístroji a ovladači, správa kanálů a proměnných. Funkčnost systému je tak dána především dynamicky konfigurovanou sadou komponent (např. databázové funkce, skriptování, apod.).

16 Limity vývoje systému Control Panel
Veškerý současný vývoj se týká jen systému Control Web. Malá firma nemůže zajišťovat veškerou podporu pro rozvoj OS (i velmi velké firmy s tím mají velké problémy): TCP/IP stack nedokončen, zůstal asi v polovině vývoje. Nelze sledovat překotný vývoj grafických karet a doplňovat ovladače. V souborových službách a síťování odkázán na služby DOS. Implementace použité objektové technologie způsobuje problémy s udržením binární kompatibility mezi verzemi.

17 Změna operačního systému (Control Panel pro DOS -> Control Web pro Windows)
Přechod 16 -> 32 bitů (rušení kódu ošetřujícího přechody mezi segmenty). Díky vrstevnaté architektuře „stačí jen přepsat“ nejnižší vrstvy. Některé prvky architektury sémanticky nekompatibilní (Windows GDI a USER poplatné době vzniku, s řadou omezení a nedokonalostí): Rozdílné šíření událostí. Rozdílný způsob překladu znakových událostí. Nesymetrie Windows (Overlapped, Popup, Child window, …). Chybná implementace překreslovacích mechanismů Windows. Rozdílné chování Win32 API v 9X a NT verzích Windows.

18 Změna vnitřní architektury
Control Panel implementoval kooperativní multitasking: Objekty reagovaly na události. „Souvislá“ činnost byla vykonávána v rámci zpracování „Event Idle“ událostí. Změna stavu detekována dotazováním. Control Web pracuje v preemptivním multitaskingu: „Souvislá“ činnost v samostatných prováděcích tocích. Změna stavu signalizována prostřednictvím synchronizačních objektů Win32 API.

19 Runtime knihovny jazyka Modula-2
Nejprve bylo nutno implementovat základní runtime knihovnu (moduly Str, Lib, FIO, …). Některé funkce implementovány kompletně (např. Str, část Lib), jiné navázány na runtime podporu C/C++ (např. FIO, Storage). Řada modulů runtime knihovny postupně přibyla (např. modul „dstr“ pro dynamické řetězce nebo modul „os“ obsahující systémově závislé funkce, třeba práci s 64 bitovým časem).

20 Views pro Windows – zase další GUI knihovna
Na rozdíl od podobných objektových knihoven (Borland OWL nebo Microsoft MFC), které byly tvořeny se sémantikou Win32 API na mysli, sémantika knihovny Views byla dána. Nutnost dodržet kompatibilitu s existujícím kódem: Události jsou distribuovány výhradně v režii Views, ať již je Windows pošlou kamkoliv. Mechanismy překreslování (okamžitého, zpožděného, vynuceného) jsou implementovány pomocí Windows API. Nově bylo zapotřebí implementovat (poněkud nešťastné) rozlišení mezi client a non-client area Windows.

21 Abstraktní datové struktury
Vše je seznam (pokud na rychlosti moc nezáleží)… … nebo vyvažovaný binární (AVL) strom (pokud je rychlé hledání kritické). Všechny abstraktní datové struktury jsou implementovány pomocí objektů. Řada struktur je implicitně obsažena v např. v hierarchii GUI tříd (Views): Každé View (Window) je v seznamu svých sousedů. NodeView mohou obsahovat celý seznam pod-Views. Hierarchie Views tak tvoří tak obecný strom, který definuje vizuální podobu i šíření událostí.

22 Další datové struktury
V některých případech nevyhoví ani seznam ani strom: Dynamická alokace elementů může být z výkonnostních důvodů neúnosná. Pak je nahrazena např. dynamickým polem (složitost hledání 1) nebo seznamem navazovaným v již alokovaných strukturách (třeba ve stromu). Pro několik instancí zpravidla vyhoví jakákoliv konstrukce. Problémy se objeví, pokud algoritmus nepracuje s několika instancemi, ale několika desítkami tisíc instancí (tzv. „množstevní rabat“ ).

23 A trochu diskrétní matematiky…
Skriptovací jazyk popsán LL(1) gramatikou. Parser implementován technikou rekurzívního sestupu. Zotavení po chybě spíše empirické (dává lepší výsledky než důsledné dodržování pravidel). Dramatická většina konstrukcí je ale „řemeslně-programátorská“. Třeba syntakticky závislé obarvení textu v editoru. Undo-Redo. A prakticky všechno ostatní mimo překladače.

24 Ukázka

25 Kapitola 2: Pokus o abstrakci
Program nikdy nedělá to, co chceme, ale jen to, co naprogramujeme. (Murphy)

26 Převod algoritmu do strojové podoby
První ENIAC i dnešní procesory Pentium či Athlon v podstatě jen vykonávají více či méně triviální instrukce (jen s každou novou generací procesorů se rychlost vykonávání instrukcí dramaticky zvyšuje). Přesto, že základní principy práce počítačů se mnoho let nemění, disciplína jejich programování zaznamenala nesmírný pokrok.

27 Začalo to strojovou instrukcí
Instrukční soubor procesoru (počítače) je definován mikroarchitekturou procesorů. Kód instrukce (přečtený z paměti programu) je zpracován řadičem mikroinstrukcí nebo přímo obvody procesoru. V moderních procesorech je zpracování instrukcí mnohem složitější, principy ale zůstávají stejné. První programy vznikaly jako soubory kódů instrukcí, zapisované přímo do paměti počítače (např. přes tzv. switch register).

28 Boj o efektivitu S rozšířením používání počítačů rostly požadavky na jejich efektivnější programování. Práce se strojovými instrukcemi vyžadovala expertní znalosti celého systému. Assembler (jazyk symbolických adres) využívá skutečnosti, že k programu samotnému lze přistupovat jako k datům, a lze ho tedy zpracovávat jiným programem. Část tíhy tvorby programu (např. výpočty cílových adres skoků) tedy na sebe bere jiný program.

29 Mezníky ve vývoji informačních technologií
Operační systém: Aplikace nepracují přímo na „holém železe“. V paměti je neustále přítomen kód, který aplikace mohou používat a který řeší přístup k periferiím a přidělování zdrojů. Funkce operačních systémů s časem narůstaly, jak se rozšiřovalo množství jimi poskytovaných služeb – virtualizace paměti, souborový systém, multiprocesing, apod. Vyšší programovací jazyk: Formulace algoritmu je výrazně usnadněna díky symbolickému zápisu.

30 A máme tu krizi software
Software se objevuje ve stále větším množství produktů a musí jej vytvářet stále větší okruh lidí, jejichž znalosti informačních technologií se relativně zmenšují. Přesto že software prostupuje náš každodenní život, současně se jej nedostává a také způsobuje řadu potíží. Často se tak hovoří o „krizi software“. Nelze přesně říci, kdy „krize“ začala, ani kdy a za jakých podmínek skončí. Spíše jen označení „krize software“ permanentně označuje problémy s tvorbou software spojené.

31 Příčiny „krize“? Proč hovoříme o „krizi“?
Software se velmi obtížně vytváří a udržuje. Nestíhají se slíbené termíny vývoje. Programy mají nízkou kvalitu (jsou i výjimky ). Velké množství projektů nebylo vůbec realizováno nebo bylo dodáno a nebylo možné je použít nebo si alespoň vyžádalo úpravy. Proč nemáme podobnou krizi např. v automobilovém průmyslu?

32 Zvláštnosti software Software se od ostatních oblastí průmyslu dosti liší. Počítače jsou naprosto nejuniverzálnější stroje – dokáží zpracovat „jakoukoliv“ informaci. Prakticky neexistují hranice – často nelze stanovit co program dělat může a co už ne. Počítače dokáží s informacemi zacházet naprosto virtuózně: Např. chyba na desce plošných spojů znamená úpravu návrhu, zaslání do výroby, výrobou nové desky, osazení novými součástkami, hledání další chyby (spousta času a peněz, lidé se proto drží zkrátka). U software se doplní IF a jede se dál (meze se nekladou).

33 Jak dál? Často proklamovaný „návrat ke kořenům“ – omezení funkčnosti, ořezání vlastností (hlavně když to bude fungovat!) asi není cesta. Bobtnání software není vina jen programátorů. Většinu bobtnání mají na svědomí požadavky zákazníků a je tedy diktováno trhem: Lidé nemají času a energie nazbyt a tak zcela zásadní vlastnost je automatičnost – ať to nějak software udělá, jen ať po mě nechce abych něco studoval, něco rozhodoval… K tomu je zapotřebí efektní a atraktivní vzhled. Řešení je asi v pozvolném učení se z chyb a evolučním zdokonalování softwarové technologie.

34 Jak posoudit kvalitu software?
Zřejmě neexistují obecně platná kritéria. Volba kritérií velmi záleží na cílové skupině uživatelů: Software pro osobní použití je psán, pokud autor má čas a chuť. Neexistují pravidla pro posuzování takového software (každému autorovi se jeho programy samozřejmě líbí nejvíce :-). Software pro omezenou skupinu je psán, pokud jej skupina akceptuje. Software komerční musí poskytnout dostatek prostředků pro financování vývojového týmu, hardware, propagace a režií firmy.

35 Kritéria přežití software
Různé skupiny uživatelů hodnotí software podle rozdílných kritérií Obecně ale platí, že uživatel potřebuje udělat svoji práci. V tom je mu bráněno důmyslnými způsoby: Nedostatečná spolehlivost software (aplikace padá). Aplikace není dokončena (zastará dříve, než je dokončena, dojdou peníze). Nedostatečná srozumitelnost (uživatel tomu nerozumí). Žádné z těchto kritérií nelze brát absolutně. Například s padací aplikací lze dobře pracovat, pokud často ukládáte (mnohé aplikace raději automaticky ukládají samy ).

36 Srozumitelnost uživatelského rozhraní
Srozumitelnosti nelze docílit žádnou obecnou technikou. Návrh srozumitelného uživatelského rozhraní je téměř výhradně záležitostí jeho tvůrců, neboť kritéria srozumitelnosti silně závisí na cílové skupině uživatelů (uživatelské rozhraní software pro ženy v domácnosti se asi bude lišit od software pro správce informačních systémů). Na pomoc mohou přijít obecné směrnice publikované firmami produkujícími operační systémy (Microsoft, Apple).

37 Spolehlivost a včasné dokončení
Spolehlivost a včasné (rychlé) dokončení jsou protichůdné požadavky. Naprogramovat jde všechno, pokud je dost času a peněz. Dost času a peněz není nikdy. (Murphy) Přesto oba požadavky bývají plněny podobnými prostředky: Použití vhodných programovacích technologií. Použití vhodných vývojových nástrojů.

38 Technologie programování
Pokusů zefektivnit programování zavedením různých technologií byla celá řada. Týkají se samotné tvorby programu (kódování): Strukturované programování. Objektově-orientované programování. Skriptování komponent. Ale také dalších technologií, nesouvisejících přímo se způsoby zápisu kódu. Abstraktní datové struktury. Teorie grafů a automatů. A řada dalších.

39 Strukturované programování
Jazyk Pascal on N. Wirtha (ETH) přináší programovací techniky označované jako strukturované. Jejich použití spolu s vlastnostmi Pascalu dokáže zefektivnit a zbezpečnit vývoj software. Zamezuje se chybám, které např. stály stovky mil. USD při havárii sondy Mariner-2. DO100I=1.10 ... CONTINUE

40 Objektově orientované programování…
Poprvé se objevuje u jazyka Smalltalk v polovině 80. let. Principy OOP jsou ale použity i v řadě jiných jazyků. Masového rozšíření dosáhlo OOP s příchodem C++ a také překladače Turbo Pascal, který od verze 5.5 podporoval třídy.

41 …není pro všechny? Objektovému programování byla připisována velká budoucnost. Přesto ale Úspěšnost dokončení softwarových projektů využívajících OOP v roce 1991 byla 92%. V roce 1993 jen 66%. Jak je to možné? OOP prokázalo své výhody v oblasti znovupoužití kódu, nikoliv však jako prostředek vystihující přirozené vlastnosti systémů a jako snadný a lehce pochopitelný model. Snižování úspěšnosti dokončení OO projektů je dáno zapojením méně kvalitních programátorů do těchto projektů, kteří již nejsou schopni kvalitní analýzy.

42 Objekt Objekt jako programová entita má tři základní charakteristiky:
Zapouzdření (encapsulation). Data (stavová informace) a metody jež tímto stavem manipulují jsou součástí jediné struktury - třídy objektu. Tyto struktury lze libovolně deklarovat nebo dynamicky tvořit v paměti - instance objektu. Metody pak manipulují jen se svými vlastními daty. Dědičnost (inheritance). Novou třídu lze vytvořit jako potomka jiné třídy. Obecně platí, že datové položky lze jen přidávat, zatímco metody lze přidávat i měnit stávající. Mnohotvarost (polymorphism). Mnohotvarost bývá realizována dynamickou vazbou na metody. Volání metody tedy není volání kódu na pevné adrese, ale volání nepřímé. Dvě instance objektů z hlediska volajícího stejného typu (stejné třídy) tak mohou mít různé implementace jediné metody - mohou se chovat různě.

43 OO analýza

44 Skriptování komponent
Stále více se prosazuje model vývoje software, který se dosti liší od tradiční představy programu, psaného v programovacím jazyce, který bude přeložen a spuštěn jako proces. Tento způsob přestává stačit nárokům na rychlý a efektivní vývoj, znovupoužití existujícího kódu, integraci s jinými systémy (databázemi, systémy přenosu zpráv, systémy autentizace apod.). Relativně malé množství kódu využívající existujících komponent dokáže vykonat velké množství práce.

45 Jaký vývojový nástroj zvolit pro nejefektivnější dosažení cíle?
Každý projekt má své specifické požadavky. Při volbě nástroje je nutno zvážit řadu věcí. Jaké nástroje jsou na trhu k dispozici? Jaký nejefektivnější nástroj lze pro daný projekt použít? Nemá význam programovat v C kreslení grafů a analýzu dat, pokud totéž s použitím tabulkového kalkulátoru zabere jen zlomek času. Na druhé straně nelze použít tabulkový kalkulátor pro programování ovladače periferního zařízení. Jaké jsou schopnosti (znalosti, zkušenosti) týmu lidí, který je k dispozici? Existují nástroje speciálně navrhované pro danou třídu úloh?

46 Volba správného vývojového prostředku
Jazyk Úroveň Assembler 1 Ada 83 4,5 AWK 15 C 2,5 C++ 6,5 Cobol 3,5 Excel (tabulkový kalkulátor) ~50 Lisp 5 Modula-2 4 Pascal Perl Smalltalk Visual Basic v3 10