Softwarové inženýrství I Návrh softwaru RNDr. Michal Žemlička, Ph.D. Vysoká škola finanční a správní Zimní semestr 2013/2014
Návrh softwaru k čemu to? Udělat cokoliv většího bez plánu je riskantní záležitost. Velký program za nás žádná neviditelná ruka softwaru kvalitně nevytvoří. Abychom mohli dobře plánovat, bývá výhodné se poučit s čím uspěli ti před námi. Podíváme se na hrubý i jemnější návrh, na některé architektonické prvky i na srovnání některých přístupů k návrhu softwaru.
Návrhový proces Obecný model návrhu softwaru je orientovaný graf. Cílem tohoto procesu je vytvoření dané struktury bez nekonsistencí. Náčrt/osnova neformálního návrhu Neformální návrh Formálnější návrh Hotový návrh
Návrhové aktivity 1. Architekturní návrh. Identifikace a dokumentace subsystémů a jejich vztahů. 2. Abstraktní specifikace. Pro každý subsystém je provedena abstraktní specifikace služeb, které podporuje, i omezení, za kterých musí fungovat. 3. Návrh rozhraní. Pro každý subsystém je navrženo a zdokumentováno rozhraní k ostatním částem. 4. Návrh komponent. Služby jsou rozmístěny do jednotlivých komponent a jsou vytvořena rozhraní těchto komponent. 5. Návrh datových struktur. Podrobný návrh datových struktur použitých k implementaci systému. 6. Návrh algoritmů. Podrobný návrh a popis algoritmů použitých k poskytování služeb.
Metody návrhu Model toku dat. Systém je modelován pomocí transformací dat. Entitně-relační model. Popisuje logické datové struktury. Strukturovaný model. Dokumentuje systémové komponenty a jejich interakci. Objektově-orientovaný model. Měl by obsahovat: model dědičnosti, model skládání objektů a obvykle i model toho, jak jsou objekty využívány jinými objekty.
Popis návrhu 1. Grafické notace Používají se k zobrazení vztahů mezi komponentami a k navázání systému na reálný svět, který modeluje. Grafický pohled je abstraktním pohledem. Bývají velmi výhodné pro získání celkového přehledu. 2. Jazyky popisu programu (program description languages, PDL). Tyto jazyky využívají řídící a strukturní konstrukty založené na programovacích jazycích, ale také vysvětlující text a někdy též další typy příkazů. To umožňuje zachytit spíše záměr návrháře než implementační detaily. 3. Neformální text. Mnoho z infomací spojených s návrhem nemůže být vyjádřeno formálně. Některé záměry mohou být lépe vyjádřeny textem.
Návrhové startegie 1. Funkční/praktický návrh. Systém je navržen z funkčního pohledu postupným zjemňováním shora dolů. Zástupci thoto přístupu jsou: Strukturovaný návrh [1] SSADM [2, 4] postupné zjemňování [5, 6] 2. Objektově orientovaný návrh. Systém je nahĺıžen jako kolekce objektů. OON vychází z myšlenky skrývání infomace [3] a byl popsána mnoha autory.
Koheze Koheze komponenty je míra nebo bĺızkost vztahů mezi jejími částmi. Komponenta by měla realizovat jednu logickou funkci nebo jednu logickou entitu. Koheze je významnou charakteristikou, protože znamená, že jednotka implementuje jednu část řešení problému.
Koheze (2) Constatnitne a Yourdon [1] rozlišují 7 úrovní koheze s rostoucí silou: 1. Náhodná koheze části komponenty nejsou provázány, jsou prostě zabaleny do jedné komponenty; 2. Logická asociace části vykonávající podobnou funkci jako ošetření vstupu nebo tiskové výstupy jsou zabaleny dohromady; 3. Temporální koheze všechny části se aktivují ve stejnou dobu (například spuštění nebo vypnutí) jsou zabaleny dohromady; 4. Procedurální koheze části komponenty tvoří jednu řídící sekvenci; 5. Komunikační koheze všechny části komponenty pracují nad stejnými vstupními daty nebo produkují stejná výstupní data; 6. Sekvenční koheze výstup jedné části slouží jako vstup pro nějaké další části; 7. Funkční koheze každá část komponenty je potřebná pro výkon jedné funkce.
Koheze (3) Popsané třídy nejsou striktně definovány. Původní dokument je funkční. Můžeme tak přidat ještě další stupeň: 8 Objektová koheze každá operace provádí funkcionalitu umožňující modifikovat, kontrolovat, nebo používat atributy objektu;
Adaptabilita Adaptabilita návrhu je obecné očekávání toho, jak snadno jde návrh měnit. Komponenty musí být volně spojené. Pro vysokou adaptabilitu je vhodné, aby komponenta byla samostatná (self-contained) aby nebyla závislá na dalších, externích, komponentách. To je v rozporu s maximální znovupoužitelností a s tím, aby bylo jedno místo opravy. Návrhář tak musí zvolit vhodný kompromis mezi znovupoužitelností a adaptabilitou.
Návrh datových toků (Data-Flow Design) Ukazuje, jak data procházejí systémem a jak jsou transformována jednotlivými funkcemi systému. Bývá možné odvodit tento model od modelu datových toků získaného v analýze. Diagramy datových toků podporují hierarchické členění. To usnadňuje jejich návrh i porozumnění v případě rozsáhlejších modelů. Grafické zobrazení se v různých CASE nástrojích výrazně liší; je třeba se nejdříve ujistit, jak to je v daném systému.
Systémy pracující v reálném čase Na jejich práci je kladen další požadavek: jednotlivé funkce musí být vykonány do určité doby od vyvolání. 2 varianty: 1. tvrdé systémy reálného času (hard real-time systems) časová omezení musí být doržena, jinak hrozí velký problém; 2. měkké systémy reálného času (soft real-time systems) časová omezení je třeba dodržet, ale občasné mírné nedodržení nevadí, pokud se limity v součtu dodrží.
Systémy pracující v reálném čase důsledky Při požadavku na krátkou odezvu funkce nelze spoléhat na zásah člověka jednoduše za setinu sekundy reagovat nestihne (natož aby si reakci rozmyslel). V mnoha systémech reálného času nelze použít pevný disk ani jiné periferie s proměnnou dobou odezvy. Toto je typické spíše pro systémy či funkce pracující v režimu hard real-time. I v systémech označovaných jako hard real-time bývají části, pro které ve skutečnosti stačí podmínka soft real-time. Někdy takové systémy obsahují i části, které mohou fungovat jako dávka (běží, dokud nedoběhnou). Hard real-time operace mohou mít zakázánu alokaci paměti (tedy žádná Java, C#, php nebo jiné jazyky, které si alokují nebo dokonce čistí pamět ve vlastní režii).
Systémy pracující v reálném čase pokračování Systémy pracující v reálném čase: nesmí vypadnout je třeba je vyvíjet s výrazně větším důrazem na spolehlivost; musí počítat to, co je od nich požadováno (pokud místo brzd vyvoláme akceleraci, může to pro mnoho lidí skončit velmi špatně); nesmí ztrácet pamět (musí vydržet v provozu bez restartu dlouhou dobu); by měl počítat s problémy a mít definovaný bezpečný stav, do kterého v případě problémů přejde. Webové aplikace vykazují mnohé vlastnosti soft real-time může být výhodné se při jejich tvorbě ve světě soft real-time inspirovat.
L. L. Constantine and E. Yourdon. Structured Design. Prentice-Hall, Englewood Cliffs, NJ, 1979. G. Cutts. Structured systems analysis and design methodology. In H.-J. Bullinger, editor, Information Technology for Organzational Systems, pages 363 370, Amsterdam, 1988. Elsevier. D. L. Parnas. Designing software for ease of extension and contraction. IEEE Transactions on Software Engineering, 5(2):128 138, 1979. P. Weaver. Practical SSADM, vesrion 4. Pitman, London, 1993. N. Wirth. program development by stepwise refinement. Communication of the ACM, 14(4):221 227, 1971.
N. Wirth. Systematic Programming: An Introduction. Prentice-Hall, Englewood Cliffs, NJ, 1976.