Programování

Úvod do „Design Techniques“

Na loňské konferenci JavaOne jsem se zúčastnil zasedání, na kterém mluvčí hovořil o plánu společnosti Sun pro virtuální stroj Java (JVM). V této přednášce řečník uvedl, že Sun plánuje mimo jiné vyčistit aktuální úzká místa ve svém virtuálním stroji, jako je pomalost synchronizovaných metod a náklady na výkon při odstraňování odpadu. Řečník uvedl cíl společnosti Sun: S vylepšením JVM by programátoři nemuseli při navrhování svých programů přemýšlet o tom, jak se vyhnout problémovým místům virtuálních strojů; stačilo by přemýšlet o vytvoření „dobrých objektově orientovaných návrhů bezpečných pro vlákna“.

Řečník však nerozpracoval, co ve skutečnosti představuje dobrý objektově orientovaný design bezpečný pro vlákna. To je cílem tohoto nového sloupce. Prostřednictvím článků Techniky návrhu sloupec, doufám, že odpovím na otázku: Co je dobrý design programu Java a jak jej vytvořit?

Zaměření sloupce

V tomto sloupci se zaměřím na poskytnutí praktických návrhových technik, které můžete použít při každodenních programovacích úkolech. Předpokládám, že jste obeznámeni s jazykem Java a API. Mám v plánu diskutovat o technikách, nápadech a pokynech, které vám pomohou používat jazyk a API ve vašich reálných programech.

Abychom měli představu o tom, co můžete v tomto sloupci očekávat, je zde seznam druhů témat, o kterých plánuji psát:

  • Způsoby, jak vylepšit design vašich objektů
  • Vytváření hierarchií tříd
  • K čemu jsou rozhraní?
  • Jaký má smysl polymorfismus?
  • Volba mezi složením a dědičností
  • Návrh pro bezpečnost závitů
  • Navrhování pro spolupráci vláken
  • Architektura Model / Controller / View používaná třídami JFC
  • Designové vzory

Hodně z materiálu, který již byl o softwarovém designu napsán, lze aplikovat na Javu. Existuje mnoho plnohodnotných metodik designu a obsáhlých učebnic, které je popisují. V tomto sloupci nebudu propagovat jednu metodiku nad druhou. Nepropaguji ani novou metodiku vlastního vynálezu. Spíše využiji a zkombinuji poznatky, které jsem získal z několika existujících metodik a které jsem ve své vlastní programovací praxi shledal užitečnými.

Přístup k designu, který v těchto článcích doporučím, vychází z mých zkušeností v průběhu let v kabině: návrh nového softwaru, vylepšení starého softwaru, údržba softwaru napsaného ostatními, údržba softwaru napsaného mnou, práce s různými jazyky, nástroji, počítače a další programovatelné stroje. Moje filozofie designu bude velmi „orientovaná na skříň“: založená na reálném komerčním programování a zaměřená na něj.

Tento měsíc: Popsaný proces, definován „design“

V tomto počátečním článku Techniky návrhu Ve sloupci uvedu podrobný popis konceptu softwarového designu na základě mé vlastní zkušenosti jako vývojáře. Ve zbývající části tohoto článku budu diskutovat o procesu vývoje softwaru a vysvětlím, co mám na mysli pod pojmem „design“.

Proces vývoje softwaru

Podle mých zkušeností je proces vývoje softwaru spíše chaotický. Členové týmu přicházejí a odcházejí, mění se požadavky, mění se plány, celé projekty se ruší, celé společnosti končí v podnikání atd. Úkolem programátora je úspěšně se orientovat v tomto chaosu a nakonec vyrobit „kvalitní“ produkt „včas“.

Kromě toho, že je proces vývoje softwaru chaotický, má tendenci být spíše iterativní. Jak je vyvíjen softwarový produkt, neustále se vyvíjí na základě zpětné vazby od mnoha stran. Tento iterativní proces funguje od vydání k vydání (každé vydání je jedna iterace) a v rámci vývojového cyklu jednoho vydání. Od vydání k vydání například zpětná vazba zákazníků s aktuální verzí naznačuje, které opravy chyb a vylepšení jsou v příští verzi nejdůležitější provést. V rámci vývojového cyklu jednoho vydání je vize konečného cíle průběžně upravována silami uvnitř společnosti, jak vývoj postupuje.

Navzdory chaosu a iteracím jsem však zjistil, že většina vývojových týmů se snaží prosadit určitou strukturu svého vývojového úsilí. Pro účely tohoto sloupce volně rozdělím proces vývoje softwaru v jednom cyklu vydání na tyto čtyři fáze:

  1. Specifikace
  2. Design
  3. Implementace
  4. Integrace a testování

S těmito čtyřmi fázemi mám v úmyslu zachytit strukturu, kterou jsem pozoroval u většiny projektů vývoje softwaru. Protože každá společnost je jiná, každý tým je jiný a každý projekt je jiný, tvoří tyto čtyři fáze jen hrubý nástin typického vývojového cyklu. V praxi mohou být některé fáze přeskočeny nebo se mohou stát v jiném pořadí. A protože iterační povaha vývoje softwaru má tendenci probublávat se jakoukoli uloženou strukturou, mohou se tyto fáze do určité míry překrývat nebo krvácet do sebe.

Když mluvím o designu v Techniky návrhu sloupec, mluvím o aktivitách, které probíhají během druhého kroku výše uvedeného seznamu. Abychom vám poskytli lepší představu o tom, co mám na mysli v jednotlivých fázích, popisuji každou zvlášť v následujících čtyřech částech.

Fáze 1: Určení problémové domény

The fáze specifikace softwarového projektu zahrnuje spojení všech zúčastněných stran k diskusi a definování konečného produktu procesu vývoje softwaru. Během specifikace definujete „vizi“ - cíl, na který se budete zaměřovat pro zbytek projektu. Výstupem, který by měl vyjít z fáze specifikace, je písemný dokument, který definuje požadavky softwarového systému.

Specifikace požadavků se podobá smlouvě. Jedná se o smlouvu mezi všemi zúčastněnými stranami, ale co je nejdůležitější z pohledu vývojáře, jedná se o smlouvu mezi vývojářem a jakoukoli stranou, která si na prvním místě přeje konečný produkt: možná klient, zákazník, vedení nebo marketingové oddělení . Pokud je specifikace vyslovena ústně, ale není zapsána, jedná se v zásadě o ústní smlouvu. Přestože je ústní smlouva právně závazná, v mnoha případech není recept na něco, co je receptem, problém. Různí lidé mají tendenci mít různé vzpomínky na ústní dohody, zejména pokud jde o podrobnosti. Neshoda v podrobnostech je ještě pravděpodobnější, pokud by podrobnosti nikdy nebyly projednány jako součást ústní dohody, což je společný rys ústních smluv.

Když se všechny zúčastněné strany sejdou a pokusí se zapsat požadavky na softwarový projekt, vynutí si to průzkum problémová doména. Problémovou doménou je konečný produkt popsaný v lidském (nikoli počítačovém programovacím) jazyce. Stejný konečný produkt vyjádřený v počítačovém jazyce je doména řešení. V průběhu zkoumání problémové oblasti lze identifikovat a diskutovat o mnoha nejednoznačných detailech a neshody lze vyřešit hned od začátku.

Dobrá specifikace vám dává přesně definovaný cíl, na který se budete při vývoji zaměřovat. Nezaručuje to však, že se cíl nepohybuje. Některé úpravy ve vizi konečného produktu jsou během fáze návrhu a implementace téměř nevyhnutelné; dobrá specifikace však může pomoci snížit rozsah těchto úprav. Přeskočení fáze specifikace nebo nedostatečné pokrytí podrobností může vést ke stejnému druhu nedorozumění mezi stranami, ke kterému může dojít při ústní smlouvě. Mít nejprve dobrou specifikaci tedy pomáhá posunout následné fáze návrhu a implementace do úspěšného konce.

Fáze 2: Návrh domény řešení

Jakmile budete mít písemnou specifikaci, se kterou všichni zúčastnění souhlasí, jste připraveni na to, čemu říkám fáze návrhu - proces plánování a nějakým způsobem dokumentování architektury vaší domény řešení. Mnoho aktivit zahrnuji pod názvem „design“, včetně:

Definování systému:

  1. Rozdělení systému do jednotlivých programů (a jeho dokumentace)
  2. Definování a dokumentace rozhraní mezi jednotlivými programy
  3. Rozhodování o a dokumentování knihoven třetích stran (balíčků Java), které vaše programy Java budou používat
  4. Při rozhodování a dokumentování nových knihoven (balíčků Java) vytvoříte, že bude sdílet více komponent vašeho systému

Vytváření prototypů uživatelského rozhraní:

  1. Vytváření prototypů uživatelského rozhraní pro ty komponenty systému, které mají jakékoli uživatelské rozhraní

Dělat objektově orientovaný design:

  1. Navrhování a dokumentování hierarchií tříd
  2. Návrh a dokumentace jednotlivých tříd a rozhraní

Definování systému

Jako první krok ve fázi návrhu musíte rozdělit systém na jednotlivé součásti. Můžete například vyžadovat několik procesů na různých místech v síti. Můžete mít nějaké applety a některé aplikace. Některé součásti systému mohou být určeny k zápisu v Javě a jiné nikoli. Pokud chcete použít JDBC, možná budete muset vybrat knihovnu JDBC jiného výrobce, která vám umožní přístup k databázi podle vašeho výběru. Všechna tato rozhodnutí musí být učiněna, než budete moci zahájit jakékoli objektově orientované návrhy jednotlivých programů v systému.

Při definování systému budete pravděpodobně chtít dokumentovat svou práci v jedné nebo více technických specifikacích. Dokumentace umožňuje komunikovat návrh dalším zainteresovaným stranám v organizaci a získat jejich zpětnou vazbu. Můžete předat specifikaci, zavolat schůzku k posouzení návrhu a poté na schůzi předložit návrh systému. Skupina může prodiskutovat váš návrh a doufejme, že najde nějaké problémy a navrhne. Získání zpětné vazby - a provedení úprav vašeho systému v důsledku zpětné vazby - je příkladem iterace v procesu vývoje softwaru.

Vytváření prototypů uživatelského rozhraní

Vytváření prototypu uživatelského rozhraní je často cennou aktivitou během fáze návrhu. Po dokončení prototypu uživatelského rozhraní se strany, které souhlasily se specifikací, mohou znovu shromáždit, aby zkontrolovaly verzi náhledu. Mít prototyp dává stranám další šanci vizualizovat a diskutovat o konečném cíli. Tím, že budete vyžadovat, aby každý, kdo souhlasil se specifikací, zkontroloval a podepsal prototyp uživatelského rozhraní, pomůžete zajistit, aby všechny strany měly kompatibilní očekávání pro konečný produkt. Díky vizuálním nástrojům, které jsou dnes k dispozici pro vývoj uživatelských rozhraní založených na prostředí Java, může být vývoj prototypu uživatelského rozhraní velmi rychlý a konečným výsledkem je rámec kódu Java, který můžete během fáze implementace vybavit funkcemi.

Všimněte si, že proces demonstrace prototypu uživatelského rozhraní je ukázkovým příkladem iterativní povahy vývojového procesu. Když zúčastněné strany (které se shodly na písemné specifikaci) skutečně vidí prototypy uživatelského rozhraní, mají často nové nápady nebo lepší porozumění nebo podrobnější porozumění - jinými slovy jasnější vizi - konce produkt. Během demonstrace mohou být provedeny určité úpravy specifikace. Doufejme však, že do této doby budou úpravy malé.

Dělat objektově orientovaný design

Při navrhování programu Java musíte myslet na všechny programovací technologie nabízené jazykem Java, včetně multithreadingu, uvolňování paměti, strukturovaného zpracování chyb a orientace na objekty. Přesto, že dominantní architektonickou charakteristikou programovacího jazyka Java je objektová orientace, je fáze návrhu programu Java v zásadě procesem objektově orientovaného designu.

Provedení objektově orientovaného designu zahrnuje vytvoření hierarchií dědičnosti a návrh polí a metod jednotlivých tříd a rozhraní. Tři základní kategorie tříd, které v designu vymyslíte, jsou:

  1. Třídy uživatelského rozhraní
  2. Problémové doménové třídy
  3. Třídy správy dat

Třídy uživatelského rozhraní jsou ty, které tvoří uživatelské rozhraní programu, například třídy, které představují okna a dialogy. Problémové doménové třídy jsou ty, které představují objekty, které jste identifikovali v problémové doméně. Například pokud vaše problémová doména zahrnovala výtahy, můžete mít Výtah třídy ve vaší doméně řešení. Třídy správy dat jsou ty, které vytvoříte pro správu objektů nebo dat. Třídy uživatelského rozhraní ani třídy správy dat nemají odpovídající objekty v problémové doméně.

Fáze 3: Implementace

Implementace je kódování. Psaní pro smyčky, příkazy if, klauzule catch, proměnné a komentáře; kompilace; testování jednotky; oprava chyby - to je implementace: ostrý akt programování.

Fáze 4: Integrace a testování

Během fáze integrace a testování se členové projektového týmu, z nichž každý má za úkol vybudovat konkrétní část celku, setkají a snaží se přimět všechny součásti softwarového systému k spolupráci. Během této fáze členové týmu zjistili, jak dobře byla definována a komunikována rozhraní mezi jednotlivými komponentami systému během fáze rozdělení systému. Kódování, které probíhá během této fáze, by mělo být primárně opravou chyby.

Dokumentace návrhů softwaru

Existuje mnoho přístupů k designu softwaru. Formální metodiky se vás pokusí provést procesem transformace problémové domény na doménu řešení. Při navrhování programů Java se můžete rozhodnout použít formální metodiku, kombinovat několik formálních metodik nebo se vzdát formální metodiky a designu podle sídla svých kalhot. Ale bez ohledu na to, jak zaútočíte na fázi návrhu vašeho softwarového projektu, měli byste nějakým způsobem dokumentovat svůj design.

$config[zx-auto] not found$config[zx-overlay] not found