Jak se dělá software

1. Jak se dělá software FIT VUT Brno 14. 5. 2002 Pavel Cagaš (pc@mii.cz) 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á, e-mail 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í 1 402 189 řádků textu. • V kódu je implementováno 2 525 tříd (classes). • Počet procedur a metod je 32 281. (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 ... 100 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