Programavimas

„Dizaino technikos“ įvadas

Praėjusių metų „JavaOne“ konferencijoje dalyvavau sesijoje, kurios metu pranešėjas kalbėjo apie „Sun“ planą sukurti „Java“ virtualią mašiną (JVM). Šioje kalboje pranešėjas pareiškė, kad „Sun“, be kita ko, planuoja išvalyti dabartines virtualiosios mašinos našumo problemas, pvz., Sinchronizuotų metodų lėtumą ir šiukšlių surinkimo našumą. Pranešėjas nurodė „Sun“ tikslą: patobulinus JVM, programuotojams nereikės galvoti, kaip išvengti virtualių mašinų kliūčių kuriant savo programas; jiems tereikės galvoti apie tai, kaip sukurti „gerą objektų, siūlų saugų dizainą“.

Tačiau kalbėtojas nedetalizavo, kas iš tikrųjų yra geras objektinis, siūlams saugus dizainas. Tai yra šios naujos skilties tikslas. Per straipsnius Dizaino technika stulpelyje, tikiuosi atsakyti į klausimą: kas yra geras „Java“ programos dizainas ir kaip jį sukurti?

Stulpelio dėmesys

Šiame stulpelyje daugiausia dėmesio skirsiu praktinėms projektavimo technikoms, kurias galėsite naudoti kasdienėse programavimo užduotyse. Darau prielaidą, kad esate susipažinę su „Java“ kalba ir API. Aš planuoju aptarti technikas, idėjas ir gaires, kurios padės jums naudoti kalbą ir API jūsų realaus pasaulio programose.

Norėdami sužinoti, ko tikėtis šiame stulpelyje, pateikite sąrašą temų, apie kurias planuoju rašyti:

  • Jūsų objektų dizaino tobulinimo būdai
  • Kurti klasių hierarchijas
  • Kam reikalingos sąsajos?
  • Kokia yra polimorfizmo prasmė?
  • Pasirinkimas tarp kompozicijos ir paveldėjimo
  • Projektavimas sriegių saugumui užtikrinti
  • Projektavimas siūlų bendradarbiavimui
  • „Model / Controller / View“ architektūra, kurią naudoja JFC klasės
  • Dizaino modeliai

Didelę dalį medžiagos, kuri jau parašyta apie programinės įrangos projektavimą, galima pritaikyti „Java“. Yra daugybė visapusiškų projektavimo metodikų ir storų jas apibūdinančių vadovėlių. Šiame stulpelyje nepropaguosiu vienos metodikos, o ne kitos. Taip pat neskatinsiu naujos savo išradimo metodikos. Veikiau remsiuosi ir sujungsiu įžvalgas, kurias įgijau iš kelių esamų metodikų ir kurios man pasirodė naudingos mano paties programavimo praktikoje.

Požiūris į dizainą, kurį rekomenduosiu šiuose straipsniuose, kyla iš mano patirties, patirtos bėgant metams: kuriant naują programinę įrangą, tobulinant seną programinę įrangą, prižiūrint kitų parašytą programinę įrangą, prižiūrint mano parašytą programinę įrangą, dirbant su įvairiomis kalbomis, įrankiais, kompiuteriai ir kitos programuojamos mašinos. Mano dizaino filosofija bus labai „orientuota į kabiną“: pagrįsta realaus pasaulio komerciniu programavimu ir orientuota į tai.

Šį mėnesį: aprašytas procesas, apibrėžtas „dizainas“

Šiame pradiniame straipsnyje Dizaino technika stulpelyje pateiksiu išsamią programinės įrangos projektavimo koncepcijos apžvalgą, remdamasi savo, kaip kūrėjo, patirtimi. Likusioje šio straipsnio dalyje aptarsiu programinės įrangos kūrimo procesą ir paaiškinsiu, ką turiu omenyje terminu „dizainas“.

Programinės įrangos kūrimo procesas

Mano patirtis rodo, kad programinės įrangos kūrimo procesas yra gana chaotiškas. Komandos nariai ateina ir išeina, keičiasi reikalavimai, keičiasi tvarkaraščiai, atšaukiami visi projektai, išjungiamos visos įmonės ir pan. Programuotojo užduotis yra sėkmingai valdyti šį chaosą ir galų gale „laiku“ gaminti „kokybišką“ produktą.

Programinės įrangos kūrimo procesas yra ne tik chaotiškas, bet ir kartojamas. Kuriant programinės įrangos produktą, jis nuolat tobulinamas, remiantis daugelio šalių atsiliepimais. Šis iteracinis procesas veikia nuo leidimo iki leidimo (kiekvienas leidimas yra viena iteracija) ir vieno leidimo kūrimo ciklo metu. Pavyzdžiui, nuo leidimo iki leidimo, klientų atsiliepimai su dabartine versija nurodo, kuriuos klaidų taisymus ir patobulinimus svarbiausia atlikti kitoje versijoje. Vieno leidimo kūrimo ciklo metu, progreso eigoje, įmonės jėgos nuolat koreguoja galutinio tikslo viziją.

Nepaisant chaoso ir iteracijos, vis dėlto pastebėjau, kad dauguma kūrėjų komandų stengiasi įtvirtinti tam tikrą savo vystymosi pastangų struktūrą. Šiame stulpelyje laisvai padalysiu vieno leidimo ciklo programinės įrangos kūrimo procesą į šias keturias fazes:

  1. Specifikacija
  2. Dizainas
  3. Įgyvendinimas
  4. Integracija ir testavimas

Per šiuos keturis etapus ketinu užfiksuoti struktūrą, kurią pastebėjau daugumoje programinės įrangos kūrimo projektų. Kadangi kiekviena įmonė yra skirtinga, kiekviena komanda yra skirtinga ir kiekvienas projektas yra skirtingas, šios keturios fazės sudaro tik apytikslį tipiško vystymosi ciklo kontūrą. Praktiškai kai kurie etapai gali būti praleisti arba gali vykti kita tvarka. Kadangi programinės įrangos kūrimo iteracinis pobūdis yra linkęs burbuliuoti per bet kokią primestą struktūrą, šios fazės gali tam tikru mastu sutapti arba kraujuoti.

Kai kalbu apie dizainą Dizaino technika stulpelyje, kalbu apie veiklą, vykstančią per pirmiau pateiktą sąrašą. Kad geriau suprastumėte, ką turiu omenyje kiekvienoje fazėje, aprašau kiekvieną atskirai kitose keturiose dalyse.

1 etapas: probleminės srities nurodymas

specifikacijos etapas programinės įrangos projekto įgyvendinimas apima visų suinteresuotų šalių subūrimą aptarti ir apibrėžti galutinį programinės įrangos kūrimo proceso produktą. Specifikacijos metu jūs apibrėžiate „viziją“ - tikslą, kurio sieksite likusiai projekto daliai. Rezultatas, kuris turėtų išeiti iš specifikacijos etapo, yra rašytinis dokumentas, apibrėžiantis programinės įrangos sistemos reikalavimus.

Reikalavimų specifikacija yra panaši į sutartį. Tai sutartis tarp visų suinteresuotų šalių, bet, svarbiausia, žiūrint iš kūrėjo perspektyvos, tai yra sutartis tarp kūrėjo ir bet kurios šalies, kuri pirmiausia nori galutinio produkto: galbūt kliento, kliento, vadovybės ar rinkodaros skyriaus . Kai dėl specifikacijos sutariama žodžiu, bet ji nerašoma, tai iš esmės yra žodinė sutartis. Nors žodinė sutartis yra teisiškai įpareigojanti, daugeliu atvejų tai, kad kažkas nėra užrašyta, yra bėdų receptas. Skirtingi žmonės paprastai skirtingai prisimena žodinius susitarimus, ypač kai kalbama apie detales. Nesutarimas dėl detalių yra dar labiau tikėtinas, jei detalės niekada nebuvo aptartos kaip žodinio susitarimo dalis, o tai yra bendras žodinių sutarčių bruožas.

Kai visos dalyvaujančios šalys susiburia ir bando užrašyti programinės įrangos projekto reikalavimus, tai priverčia tyrinėti probleminis domenas. Probleminė sritis yra galutinis produktas, aprašytas žmogaus (ne kompiuterio programavimo) kalba. Tas pats galutinis produktas, išreikštas kompiuterio kalba, yra sprendimo domenas. Tiriant probleminę sritį galima nustatyti ir aptarti daug neaiškių detalių, o nesutarimus išspręsti iš pat pradžių.

Gera specifikacija suteikia jums tiksliai apibrėžtą tikslą, kurio siekiate tobulėdami. Bet tai negarantuoja, kad taikinys nejudės. Projektavimo ir įgyvendinimo etapuose beveik neišvengiama kai kurių galutinio produkto vizijos koregavimų; tačiau gera specifikacija gali padėti sumažinti tokių koregavimų mastą. Praleidus specifikacijos etapą arba nepakankamai aprėpiant detales, tarp šalių gali kilti tokio paties pobūdžio nesusipratimų, kurie gali atsirasti sudarant žodinę sutartį. Taigi, turėdami gerą specifikaciją, pirmiausia galite sėkmingai atlikti vėlesnius projektavimo ir įgyvendinimo etapus.

2 etapas: sprendimo srities projektavimas

Turėdami rašytinę specifikaciją, su kuria sutinka visi dalyvaujantys, esate pasirengę tam, ką aš vadinu projektavimo etapas - jūsų sprendimo domeno architektūros planavimo ir tam tikru būdu dokumentavimo procesą. Aš įtraukiu daugybę veiklų pavadinimu „dizainas“, įskaitant:

Sistemos apibrėžimas:

  1. Sistemos padalijimas į atskiras programas (ir jos dokumentavimas)
  2. Sąsajų tarp atskirų programų apibrėžimas ir dokumentavimas
  3. Nuspręskite ir dokumentuokite trečiųjų šalių bibliotekas („Java“ paketus), kurias naudos jūsų „Java“ programos
  4. Spręsdami ir dokumentuodami naujas bibliotekas („Java“ paketus), sukursite, kad keliais jūsų sistemos komponentais bus dalijamasi

Vartotojo sąsajos prototipų kūrimas:

  1. Vartotojo sąsajos prototipų kūrimas tiems sistemos komponentams, kurie turi bet kurią vartotojo sąsają

Atliekant objektinį dizainą:

  1. Kuriant ir dokumentuojant klasių hierarchijas
  2. Individualių klasių ir sąsajų projektavimas ir dokumentavimas

Sistemos apibrėžimas

Pirmasis žingsnis projektavimo etape turi būti padalytas iš sistemos į sudedamąsias dalis. Pavyzdžiui, jums gali prireikti kelių procesų įvairiose tinklo vietose. Galite turėti keletą programėlių ir keletą programų. Kai kuriuos sistemos komponentus gali būti parašyta „Java“, o kitus - ne. Jei norite naudoti JDBC, jums gali tekti pasirinkti trečiosios šalies JDBC biblioteką, kuri leis jums pasiekti jūsų pasirinktą duomenų bazę. Visi šie sprendimai turi būti priimti prieš pradedant bet kokį objektyvų sistemos atskirų programų dizainą.

Apibrėždami sistemą, tikriausiai norėsite dokumentuoti savo darbą vienoje ar keliose techninėse specifikacijose. Dokumentacija leidžia pranešti apie projektą kitoms suinteresuotoms organizacijos šalims ir gauti jų atsiliepimus. Galite perduoti specifikaciją, sušaukti projekto peržiūros susitikimą, tada susitikime pristatyti sistemos projektą. Grupė gali aptarti jūsų dizainą ir, tikiuosi, rasti problemų ir pateikti pasiūlymų. Grįžtamasis ryšys - ir koreguoti sistemos dizainą dėl grįžtamojo ryšio - yra iteracijos pavyzdys programinės įrangos kūrimo procese.

Vartotojo sąsajos prototipų kūrimas

Vartotojo sąsajos prototipo kūrimas projektavimo etape dažnai yra vertinga veikla. Kai vartotojo sąsajos prototipas bus baigtas, šalys, kurios sutiko su specifikacija, gali vėl susirinkti peržiūrėti peržiūros versiją. Prototipo turėjimas suteikia šalims dar vieną galimybę vizualizuoti ir aptarti galutinį tikslą. Reikalaudami, kad visi sutikę su specifikacija peržiūrėtų ir atsijungtų nuo vartotojo sąsajos prototipo, padėsite užtikrinti, kad visos šalys turėtų suderintų lūkesčių dėl galutinio produkto. Naudojant šiandien turimus vaizdinius įrankius, skirtus „Java“ pagrindu sukurtų vartotojo sąsajų kūrimui, vartotojo sąsajos prototipo kūrimas gali būti labai greitas, o galutinis rezultatas yra „Java“ kodo sistema, kurią galite suteikti funkcionalumu įgyvendinimo etape.

Atkreipkite dėmesį, kad vartotojo sąsajos prototipo demonstravimo procesas yra pagrindinis iteracinio kūrimo pobūdžio pavyzdys. Kai suinteresuotosios šalys (kurios visos susitarė dėl rašytinės specifikacijos) iš tikrųjų mato vartotojo sąsajos prototipus, jos dažnai turi naujų idėjų, geriau supranta arba išsamiau supranta - kitaip tariant, aiškesnę viziją - apie pabaigą. produktas. Demonstracijos metu specifikacija gali būti šiek tiek pakoreguota. Tačiau šiuo metu, tikiuosi, koregavimai bus nedideli.

Atliekant objektyvų dizainą

Kurdami „Java“ programą, turite galvoti apie visas „Java“ kalbos siūlomas programavimo technologijas, įskaitant daugialypį gijimą, šiukšlių surinkimą, struktūrizuotą klaidų tvarkymą ir objektų orientaciją. Kadangi dominuojanti „Java“ programavimo kalbos architektūrinė charakteristika yra orientacija į objektą, „Java“ programos projektavimo etapas iš esmės yra į objektą orientuoto projektavimo procesas.

Objektinis dizainas apima paveldėjimo hierarchijų kūrimą ir atskirų klasių bei sąsajų laukų ir metodų kūrimą. Trys pagrindinės klasių, kurias sugalvosite, kategorijos yra:

  1. Vartotojo sąsajos klasės
  2. Probleminės domenų klasės
  3. Duomenų valdymo klasės

Vartotojo sąsajos klasės yra tie, kurie sudaro programos vartotojo sąsają, pvz., langus ir dialogus žyminčios klasės. Probleminės domenų klasės yra objektai, kuriuos jūs identifikavote probleminiame domene. Pvz., Jei jūsų probleminiame domene yra liftai, galbūt turite Liftas klasės jūsų sprendimo srityje. Duomenų valdymo klasės yra tie, kuriuos kuriate objektams ar duomenims valdyti. Nei vartotojo sąsajos klasėse, nei duomenų valdymo klasėse nėra atitinkamų objektų probleminiame domene.

3 etapas: įgyvendinimas

Diegimas yra kodavimas. Rašymas kilpoms, jei teiginiai, sugavimo sąlygos, kintamieji ir komentarai; kompiliavimas; vieneto testavimas; klaidų taisymas - tai įgyvendinimas: griežtas programavimo veiksmas.

4 etapas: integracija ir bandymai

Integracijos ir bandymo etape projekto komandos nariai, kurių kiekvienas turi užduotis sukurti tam tikrą visumos dalį, susitinka ir bando priversti visus programinės įrangos elementus veikti kartu. Šiame etape komandos nariai sužino, kaip gerai buvo apibrėžtos ir perduotos sąsajos tarp atskirų sistemos komponentų sistemos skaidymo etape. Šiame etape atliekamas kodavimas pirmiausia turėtų būti klaidų taisymas.

Programinės įrangos projektavimo dokumentavimas

Yra daugybė programinės įrangos projektavimo būdų. Formalios metodikos bando padėti jums paversti probleminę sritį į sprendimo sritį. Kurdami „Java“ programas galite pasirinkti naudoti oficialią metodiką, derinti kelias oficialias metodikas arba atsisakyti oficialios metodikos ir dizaino pagal kelnes. Nepaisant to, kaip jūs atakuojate savo programinės įrangos projekto kūrimo etapą, turėtumėte kokiu nors būdu dokumentuoti savo projektą.

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