Na minuloročnej konferencii JavaOne som sa zúčastnil stretnutia, na ktorom prednášajúci hovoril o pláne spoločnosti Sun pre virtuálny stroj Java (JVM). V tejto prednáške rečník uviedol, že spoločnosť Sun plánuje okrem iného vyčistiť súčasné úzke miesta vo výkone svojho virtuálneho stroja, ako napríklad pomalosť synchronizovaných metód a náklady na výkon pri zbere odpadu. Rečník uviedol cieľ spoločnosti Sun: Vďaka vylepšeniam JVM by programátori nemuseli pri navrhovaní svojich programov myslieť na to, aby sa vyhli prekážkam vo virtuálnych strojoch; stačilo by im len premýšľať o vytvorení „dobrého objektovo orientovaného dizajnu bezpečného pre vlákna“.
Prednášajúci však nerozpracoval, čo vlastne predstavuje dobrý objektovo orientovaný dizajn bezpečný pre vlákna. To je cieľom tohto nového stĺpca. Prostredníctvom článkov Dizajnové techniky stĺpec, dúfam, že odpoviem na otázku: Čo je dobrý dizajn programu Java a ako ho vytvoríte?
Zaostrenie stĺpca
V tomto stĺpci sa budem sústrediť na to, aby som poskytol praktické návrhové techniky, ktoré môžete použiť pri svojich každodenných programovacích úlohách. Predpokladám, že ovládate jazyk Java a API. Mám v pláne prediskutovať techniky, nápady a pokyny, ktoré vám pomôžu používať jazyk a API vo vašich skutočných programoch.
Aby ste mali predstavu, čo môžete v tomto stĺpci očakávať, uvádzam zoznam druhov tém, o ktorých plánujem písať:
- Spôsoby, ako vylepšiť dizajn svojich objektov
- Budovanie hierarchií tried
- Na čo slúžia rozhrania?
- Aký je zmysel polymorfizmu?
- Výber medzi zložením a dedičstvom
- Dizajn pre bezpečnosť závitov
- Navrhovanie pre spoluprácu vlákien
- Architektúra Model / Controller / View používaná triedami JFC
- Dizajnové vzory
Veľkú časť materiálu, ktorý už bol napísaný o dizajne softvéru, je možné použiť v prostredí Java. Existuje veľa plnohodnotných metodík návrhu a rozsiahlych učebníc, ktoré ich popisujú. V tomto stĺpci nebudem propagovať jednu metodiku pred druhou. Rovnako nebudem presadzovať novú metodológiu svojho vlastného vynálezu. Skôr budem čerpať a kombinovať poznatky, ktoré som získal z niekoľkých existujúcich metodík a ktoré sa mi osvedčili v mojej vlastnej programátorskej praxi.
Prístup k navrhovaniu, ktorý v týchto článkoch odporučím, vychádza z mojich dlhoročných skúseností v kabíne: návrh nového softvéru, vylepšenie starého softvéru, údržba softvéru napísaného ostatnými, údržba softvéru napísaného mnou, práca s rôznymi jazykmi, nástrojmi, počítače a ďalšie programovateľné stroje. Moja filozofia dizajnu bude veľmi „zameraná na kóje“: založená na komerčnom programovaní v reálnom svete a zameraná na neho.
Tento mesiac: Popísaný proces, definovaný „dizajn“
V tomto úvodnom článku Dizajnové techniky V stĺpci uvediem podrobný popis konceptu softvérového dizajnu na základe mojich vlastných skúseností ako vývojára. Vo zvyšku tohto článku sa budem venovať procesu vývoja softvéru a vysvetlím, čo mám na mysli pod pojmom „dizajn“.
Proces vývoja softvéru
Podľa mojich skúseností býva proces vývoja softvéru dosť chaotický. Členovia tímu prichádzajú a odchádzajú, zmeny požiadaviek, zmeny harmonogramov, zrušenie celých projektov, ukončenie činnosti celých spoločností atď. Úlohou programátora je úspešne sa orientovať v tomto chaose a nakoniec vyrobiť „kvalitný“ produkt „včas“.
Okrem toho, že je proces vývoja softvéru chaotický, býva tiež pomerne iteračný. Počas vývoja softvérového produktu sa neustále vyvíja na základe spätnej väzby od mnohých strán. Tento iteračný proces funguje od vydania k vydaniu (každé vydanie je jednou iteráciou) a v rámci vývojového cyklu jedného vydania. Napríklad od vydania k vydaniu spätná väzba zákazníkov s aktuálnou verziou naznačuje, ktoré opravy chýb a vylepšenia sú najdôležitejšie v budúcej verzii. V rámci vývojového cyklu jedného vydania sa vízia konečného cieľa priebežne upravuje silami v rámci spoločnosti, ako vývoj pokračuje.
Napriek chaosu a opakovaniu som však zistil, že väčšina vývojových tímov sa snaží presadiť určitú štruktúru svojho vývojového úsilia. Na účely tohto stĺpca voľne rozdelím proces vývoja softvéru v jednom cykle vydania na tieto štyri fázy:
- Špecifikácia
- Dizajn
- Implementácia
- Integrácia a test
Pomocou týchto štyroch fáz chcem zachytiť štruktúru, ktorú som pozoroval vo väčšine projektov vývoja softvéru. Pretože každá spoločnosť je iná, každý tím je iný a každý projekt je iný, tvoria tieto štyri fázy iba hrubý náčrt typického vývojového cyklu. V praxi môžu byť niektoré fázy vynechané alebo sa môžu stať v inom poradí. A pretože iteračná povaha vývoja softvéru má tendenciu prebublávať cez akúkoľvek uloženú štruktúru, môžu sa tieto fázy do istej miery prekrývať alebo krvácať jedna do druhej.
Keď hovorím o dizajne v Dizajnové techniky stĺpci, hovorím o činnostiach, ktoré sa uskutočňujú v priebehu druhého kroku vyššie uvedeného zoznamu. Pre lepšiu predstavu o tom, čo myslím v jednotlivých fázach, popisujem každú z nich osobitne v ďalších štyroch častiach.
Fáza 1: Určenie problémovej domény
The fáza špecifikácie softvérového projektu zahŕňa spojenie všetkých zúčastnených strán s cieľom prediskutovať a definovať konečný produkt procesu vývoja softvéru. Počas špecifikácie definujete „víziu“ - cieľ, na ktorý sa zameriate po zvyšok projektu. Výstupom, ktorý by mal vyjsť z fázy špecifikácie, je písomný dokument, ktorý definuje požiadavky softvérového systému.
Špecifikácia požiadaviek sa podobá zmluve. Je to zmluva medzi všetkými zúčastnenými stranami, ale čo je najdôležitejšie z pohľadu vývojára, je to zmluva medzi vývojárom a akoukoľvek stranou, ktorá si na prvom mieste želá konečný produkt: možno klient, zákazník, manažment alebo marketingové oddelenie . Ak je špecifikácia dohodnutá ústne, ale nie je napísaná, v zásade ide o ústnu zmluvu. Aj keď je ústna zmluva právne záväzná, recept na ťažkosti je v mnohých prípadoch nemanipulovateľný. Rôzni ľudia majú tendenciu mať rôzne spomienky na ústne dohody, najmä pokiaľ ide o podrobnosti. Nezhoda v detailoch je ešte pravdepodobnejšia, ak by sa o detailoch nikdy nejednalo v rámci ústnej dohody, čo je spoločná vlastnosť ústnych zmlúv.
Keď sa všetky zúčastnené strany spoja a pokúsia sa spísať požiadavky na softvérový projekt, prinúti to preskúmať problémová doména. Problémovou doménou je konečný produkt popísaný v ľudskom (nie počítačovom programovacom) jazyku. Rovnaký konečný produkt vyjadrený v počítačovom jazyku je doména riešenia. V priebehu skúmania problémovej oblasti je možné identifikovať a prediskutovať veľa nejednoznačných detailov a nezhody možno vyriešiť hneď od začiatku.
Dobrá špecifikácia vám dáva presne stanovený cieľ, na ktorý sa pri vývoji musíte zamerať. Ale to nezaručuje, že sa cieľ nepohne. Niektoré úpravy videnia konečného produktu sú vo fáze návrhu a implementácie takmer nevyhnutné. dobrá špecifikácia však môže pomôcť znížiť rozsah takýchto úprav. Vynechanie fázy špecifikácie alebo nedostatočné pokrytie podrobností môže viesť k rovnakému druhu nedorozumenia medzi stranami, ku ktorému môže dôjsť pri ústnej zmluve. Takže mať najskôr dobrú špecifikáciu pomáha posunúť následné fázy návrhu a implementácie do úspešného konca.
Fáza 2: Návrh domény riešenia
Keď budete mať písomnú špecifikáciu, s ktorou všetci zúčastnení súhlasia, ste pripravení na to, čomu hovorím fáza návrhu - proces plánovania a určitým spôsobom dokumentovanie architektúry vašej domény riešenia. Veľa aktivít uvádzam pod názvom „dizajn“, medzi ktoré patria:
Definovanie systému:
- Rozdelenie systému na jednotlivé programy (a jeho dokumentácia)
- Definovanie a dokumentovanie rozhraní medzi jednotlivými programami
- Rozhodovanie a dokumentovanie knižníc tretích strán (balíkov Java), ktoré vaše programy Java použijú
- Pri rozhodovaní a dokumentovaní nových knižníc (balíkov Java) budete zostavovať, že ich bude zdieľať viacero komponentov vášho systému
Tvorba prototypov používateľského rozhrania:
- Vytváranie prototypov používateľského rozhrania pre tie komponenty systému, ktoré majú akékoľvek používateľské rozhranie
Robiť objektovo orientovaný dizajn:
- Navrhovanie a dokumentovanie hierarchií tried
- Návrh a dokumentácia jednotlivých tried a rozhraní
Definovanie systému
Ako prvý krok vo fáze návrhu musíte rozdeliť systém na jednotlivé súčasti. Môžete napríklad vyžadovať niekoľko procesov na rôznych miestach v sieti. Môžete mať nejaké applety a niektoré aplikácie. Niektoré komponenty systému môžu byť určené na zápis v jazyku Java a iné nie. Ak chcete používať JDBC, možno budete musieť zvoliť knižnicu JDBC tretej strany, ktorá vám umožní prístup k databáze podľa vášho výberu. Všetky tieto rozhodnutia musia byť urobené skôr, ako začnete s akýmkoľvek objektovo orientovaným návrhom jednotlivých programov v systéme.
Pri definovaní systému budete pravdepodobne chcieť svoju prácu zdokumentovať v jednej alebo viacerých technických špecifikáciách. Dokumentácia umožňuje komunikovať návrh s ostatnými zainteresovanými stranami v organizácii a získať ich spätnú väzbu. Môžete rozdať špecifikáciu, zvolať schôdzu na preskúmanie návrhu a potom na schôdzi predstaviť návrh systému. Skupina môže prediskutovať váš návrh, dúfam, že nájde akékoľvek problémy a urobí návrhy. Získanie spätnej väzby - a vykonanie úprav návrhu systému v dôsledku tejto spätnej väzby - je príkladom iterácie v procese vývoja softvéru.
Vytváranie prototypov používateľského rozhrania
Vytvorenie prototypu používateľského rozhrania je často cennou aktivitou vo fáze návrhu. Po dokončení prototypu používateľského rozhrania sa môžu strany, ktoré súhlasili so špecifikáciou, opäť zhromaždiť, aby skontrolovali ukážkovú verziu. Mať prototyp dáva stranám ďalšiu príležitosť vizualizovať a prediskutovať konečný cieľ. Vyžadovaním, aby každý, kto súhlasil so špecifikáciou, skontroloval a odhlásil sa na prototype používateľského rozhrania, pomôžete zabezpečiť, aby všetky strany mali kompatibilné očakávania týkajúce sa konečného produktu. Vďaka vizuálnym nástrojom, ktoré sú dnes k dispozícii na vývoj používateľských rozhraní založených na prostredí Java, môže byť vývoj prototypu používateľského rozhrania veľmi rýchly a konečným výsledkom je rámec kódu Java, ktorý potom môžete vo fáze implementácie vybaviť funkčnosťou.
Upozorňujeme, že proces demonštrácie prototypu používateľského rozhrania je ukážkovým príkladom iteračnej povahy vývojového procesu. Keď zainteresované strany (ktoré sa dohodli na písomnej špecifikácii) skutočne vidia prototypy používateľského rozhrania, často majú nové nápady alebo lepšie pochopenie alebo podrobnejšie pochopenie - inými slovami jasnejšiu víziu - konca výrobok. Počas ukážky je možné vykonať určité úpravy špecifikácie. Dúfajme však, že do tejto doby budú úpravy malé.
Robiť objektovo orientovaný dizajn
Pri navrhovaní programu Java musíte myslieť na všetky programovacie technológie ponúkané jazykom Java, vrátane multithreadingu, odvozu odpadu, štruktúrovaného spracovania chýb a orientácie na objekty. Pretože dominantnou architektonickou charakteristikou programovacieho jazyka Java je objektová orientácia, je fáza návrhu programu Java v zásade procesom objektovo orientovaného dizajnu.
Realizácia objektovo orientovaného dizajnu zahŕňa vytvorenie hierarchií dedičstva a návrh polí a metód jednotlivých tried a rozhraní. Tri základné kategórie tried, ktoré v dizajne vymyslíte, sú:
- Triedy používateľského rozhrania
- Problémové triedy domén
- Triedy správy údajov
Triedy používateľského rozhrania sú tie, ktoré tvoria používateľské rozhranie programu, napríklad triedy, ktoré predstavujú okná a dialógové okná. Problémové triedy domén sú tie, ktoré predstavujú objekty, ktoré ste identifikovali v problémovej doméne. Napríklad, ak sa vo vašej problémovej doméne nachádzali výťahy, mohli by ste mať Výťah triedy vo vašej doméne riešenia. Triedy správy údajov sú tie, ktoré vytvoríte na správu objektov alebo údajov. Triedy používateľského rozhrania ani triedy správy údajov nemajú zodpovedajúce objekty v problémovej doméne.
Fáza 3: Implementácia
Implementácia je kódovanie. Písanie pre slučky, ak sú vyhlásenia, klauzuly o chybe, premenné a komentáre; zostavovanie; testovanie jednotky; oprava chyby - to je implementácia: ostrý akt programovania.
Fáza 4: Integrácia a testovanie
Počas fázy integrácie a testovania sa členovia projektového tímu, ktorí majú za úlohu vybudovať konkrétnu časť celku, stretnúť a pokúsiť sa o to, aby všetky časti softvérového systému spolupracovali. Počas tejto fázy členovia tímu zisťujú, ako dobre boli definované rozhrania medzi jednotlivými komponentmi systému a komunikované počas fázy rozdelenia systému. Programovanie, ktoré sa uskutoční počas tejto fázy, by malo byť predovšetkým opravou chyby.
Dokumentácia softvérových návrhov
Existuje mnoho prístupov k návrhu softvéru. Formálne metodiky sa vás pokúsia sprevádzať procesom transformácie problémovej domény na doménu riešenia. Pri navrhovaní programov Java sa môžete rozhodnúť použiť formálnu metodológiu, kombinovať niekoľko formálnych metodológií alebo sa vzdať formálnej metodiky a dizajnu podľa sídla svojich nohavíc. Bez ohľadu na to, ako zaútočíte na fázu návrhu softvérového projektu, mali by ste svoj návrh nejakým spôsobom zdokumentovať.
