Pagājušā gada JavaOne konferencē es apmeklēju sesiju, kurā runātājs runāja par Sun plānu Java virtuālajai mašīnai (JVM). Šajā runā runātājs paziņoja, ka Sun cita starpā plāno noskaidrot pašreizējās veiktspējas vājās vietas savā virtuālajā mašīnā, piemēram, sinhronizēto metožu lēnumu un atkritumu savākšanas veiktspējas izmaksas. Runātājs paziņoja Sun mērķi: Ar JVM uzlabojumiem programmētājiem nevajadzētu domāt par virtuālo mašīnu sastrēgumu novēršanu, izstrādājot savas programmas; viņiem būtu jādomā tikai par "labu objektorientētu, diegiem drošu dizainu" izveidošanu.
Runātājs tomēr nepaskaidroja, kas patiesībā ir labs uz objektu orientēts, vītnēm drošs dizains. Tas ir šīs jaunās slejas mērķis. Ar Dizaina paņēmieni kolonnā, es ceru atbildēt uz jautājumu: Kas ir labs Java programmas dizains un kā jūs to izveidojat?
Kolonnas fokuss
Mana uzmanība šajā slejā būs sniegt praktiskas dizaina metodes, kuras varat izmantot ikdienas programmēšanas uzdevumos. Es pieņemu, ka jūs labi pārzināt Java valodu un API. Es plānoju apspriest metodes, idejas un vadlīnijas, kas palīdzēs jums izmantot valodu un API jūsu reālās pasaules programmās.
Lai sniegtu priekšstatu par šajā kolonnā gaidāmajiem, šeit ir saraksts ar tēmām, par kurām plānoju rakstīt:
- Veidi, kā uzlabot jūsu objektu dizainu
- Klases hierarhiju veidošana
- Kam domātas saskarnes?
- Kāda jēga ir polimorfismam?
- Izvēle starp sastāvu un mantojumu
- Projektēšana vītņu drošībai
- Projektēšana pavedienu sadarbībai
- Model / Controller / View arhitektūra, ko izmanto JFC klases
- Dizaina modeļi
Lielu daļu materiāla, kas jau ir uzrakstīts par programmatūras projektēšanu, var attiecināt uz Java. Ir daudz pilnu dizaina metodiku un biezas mācību grāmatas, kas tās apraksta. Šajā slejā es nepopularizēšu vienu metodiku, nevis citu. Es arī neveicināšu jaunu sava izgudrojuma metodiku. Drīzāk es izmantošu un apvienošu atziņas, kuras esmu ieguvis no vairākām esošajām metodikām un kuras esmu atzinis par noderīgām savā programmēšanas praksē.
Pieeja dizainam, kuru es ieteikšu šajos rakstos, izriet no manas pieredzes, kas gadu gaitā ir bijusi kabīnē: jaunas programmatūras projektēšana, vecās programmatūras uzlabošana, citu uzrakstītās programmatūras uzturēšana, pašas rakstītās programmatūras uzturēšana, darbs ar dažādām valodām, rīkiem datori un citas programmējamās mašīnas. Mana dizaina filozofija būs ļoti “orientēta uz kabīni”: balstīta uz reālās pasaules komerciālajām programmām un orientēta uz tām.
Šomēnes: Aprakstītais process, definēts "dizains"
Šajā sākotnējā rakstā Dizaina paņēmieni kolonnā, es sniegšu detalizētu programmatūras projektēšanas jēdziena pārskatu, pamatojoties uz savu kā izstrādātāja pieredzi. Šī raksta atlikušajā daļā es apspriedīšu programmatūras izstrādes procesu un paskaidrošu, ko es domāju ar terminu "dizains".
Programmatūras izstrādes process
Pēc manas pieredzes programmatūras izstrādes process mēdz būt diezgan haotisks. Komandas locekļi nāk un iet, mainās prasības, mainās grafiki, tiek atcelti veseli projekti, izbeidzas visu uzņēmumu darbība utt. Programmētāja uzdevums ir veiksmīgi orientēties šajā haosā un galu galā "savlaicīgi" ražot "kvalitatīvu" produktu.
Papildus haotiskumam programmatūras izstrādes process mēdz būt diezgan atkārtojams. Attīstot programmatūras produktu, tas nepārtraukti attīstās, pamatojoties uz daudzu pušu atsauksmēm. Šis iteratīvais process darbojas no laidiena līdz izlaišanai (katrs laidiens ir viens atkārtojums) un viena laidiena izstrādes ciklā. Piemēram, sākot ar laidienu līdz izlaišanai, klientu atsauksmes ar pašreizējo versiju norāda, kuri kļūdu labojumi un uzlabojumi ir vissvarīgākie nākamajā versijā. Viena laidiena izstrādes cikla laikā uzņēmuma attīstībā esošie spēki nepārtraukti pielāgo mērķa redzējumu.
Neskatoties uz haosu un atkārtojumu, es tomēr atklāju, ka lielākā daļa attīstības komandu cenšas ieviest zināmu struktūru savos attīstības centienos. Šajā slejā es brīvi sadalīšu viena laidiena cikla programmatūras izstrādes procesu šajās četrās fāzēs:
- Specifikācija
- Dizains
- Īstenošana
- Integrācija un pārbaude
Ar šīm četrām fāzēm esmu iecerējis iemūžināt struktūru, kuru esmu novērojis lielākajā daļā programmatūras izstrādes projektu. Tā kā katrs uzņēmums ir atšķirīgs, katra komanda ir atšķirīga un katrs projekts ir atšķirīgs, šīs četras fāzes veido tikai aptuvenu tipiskā attīstības cikla izklāstu. Praksē dažas fāzes var izlaist vai notikt citā secībā. Tā kā programmatūras izstrādes iteratīvais raksturs mēdz burbuļot caur jebkuru uzlikto struktūru, šīs fāzes zināmā mērā var pārklāties vai asiņot.
Kad es runāju par dizainu Dizaina paņēmieni slejā, es runāju par darbībām, kas notiek iepriekš minētā saraksta otrajā posmā. Lai gūtu labāku priekšstatu par to, ko es domāju ar katru fāzi, es katru nākamo četru sadaļu aprakstu katru atsevišķi.
1. fāze: problemātiskā domēna norādīšana
The specifikācijas fāze programmatūras projekta īstenošana ietver visu ieinteresēto pušu apvienošanu, lai apspriestu un definētu programmatūras izstrādes procesa gala produktu. Specifikācijas laikā jūs definējat "vīziju" - mērķi, uz kuru jūs mērķēsiet atlikušajā projekta daļā. Rezultāts, kas jāiziet no specifikācijas fāzes, ir rakstisks dokuments, kas nosaka programmatūras sistēmas prasības.
Prasību specifikācija līdzinās līgumam. Tas ir līgums starp visām iesaistītajām pusēm, bet vissvarīgākais no izstrādātāja viedokļa ir līgums starp izstrādātāju un visu, kas vispirms vēlas galaproduktu: varbūt klientu, klientu, vadību vai mārketinga nodaļu . Ja specifikācija ir saskaņota mutiski, bet tā nav pierakstīta, tas būtībā ir mutisks līgums. Lai gan mutisks līgums ir juridiski saistošs, daudzos gadījumos tas, ka kaut kas nav pierakstīts, ir nepatikšanas recepte. Dažādiem cilvēkiem mēdz būt dažādas atmiņas par mutiskām vienošanām, īpaši attiecībā uz detaļām. Nesaskaņas par detaļām ir vēl ticamākas, ja detaļas vispirms netika apspriestas kā daļa no mutiskas vienošanās, kas ir mutisku līgumu kopīga iezīme.
Kad visas iesaistītās puses sanāk kopā un mēģina pierakstīt programmatūras projekta prasības, tas liek izpētīt problēmu domēns. Problēmas joma ir gala produkts, kas aprakstīts cilvēku valodā (nevis datorprogrammēšana). Tas pats galaprodukts, kas izteikts datorvalodā, ir risinājuma domēns. Izpētot problēmu jomu, var identificēt un apspriest daudzas neskaidras detaļas, un domstarpības var atrisināt jau no paša sākuma.
Laba specifikācija dod jums precīzi definētu mērķi, uz kuru tiecaties attīstoties. Bet tas negarantē, ka mērķis nepārvietosies. Daži pielāgojumi gala produkta redzējumā ir gandrīz neizbēgami projektēšanas un ieviešanas posmā; tomēr laba specifikācija var palīdzēt samazināt šādu pielāgojumu apjomu. Izlaižot specifikācijas fāzi vai nepietiekami aptverot detaļas, starp pusēm var rasties tāda paša veida pārpratumi, kas var notikt ar mutisku līgumu. Tādējādi laba specifikācija vispirms sekmē turpmāko projektēšanas un ieviešanas posmu veiksmīgu noslēgumu.
2. fāze: risinājuma domēna projektēšana
Kad jums ir rakstiska specifikācija, kurai piekrīt visi iesaistītie, jūs esat gatavs tam, ko es saucu projektēšanas fāze - jūsu risinājuma domēna arhitektūras plānošanas process un kaut kādā veidā dokumentēšana. Es iekļauju daudzas darbības ar nosaukumu "dizains", tostarp:
Sistēmas definēšana:
- Sistēmas sadalīšana atsevišķās programmās (un tās dokumentēšana)
- Saskarņu noteikšana un dokumentēšana starp atsevišķām programmām
- Izlemjot un dokumentējot trešo personu bibliotēkas (Java paketes), kuras izmantos jūsu Java programmas
- Izlemjot un dokumentējot jaunas bibliotēkas (Java paketes), jūs izveidosiet to, ka vairāki jūsu sistēmas komponenti tiks koplietoti
Lietotāja saskarnes prototipu veidošana:
- Lietotāja saskarnes prototipu veidošana tiem sistēmas komponentiem, kuriem ir jebkura lietotāja saskarne
Veicot objektorientētu dizainu:
- Klases hierarhiju noformēšana un dokumentēšana
- Atsevišķu klašu un saskarņu projektēšana un dokumentēšana
Sistēmas definēšana
Kā pirmais solis projektēšanas posmā jums ir jāsadala sistēma tās sastāvdaļās. Piemēram, jums var būt nepieciešami vairāki procesi dažādās tīkla vietās. Jums var būt dažas sīklietotnes un dažas lietojumprogrammas. Dažiem sistēmas komponentiem var būt paredzēts rakstīt Java valodā, bet citiem - nē. Ja vēlaties izmantot JDBC, iespējams, jums būs jāizvēlas trešās puses JDBC bibliotēka, kas ļaus piekļūt jūsu izvēlētajai datu bāzei. Visi šie lēmumi ir jāpieņem, pirms jūs varat sākt objektīvi veidot atsevišķu sistēmas programmu noformējumus.
Definējot sistēmu, jūs, iespējams, vēlēsities dokumentēt savu darbu vienā vai vairākās tehniskajās specifikācijās. Dokumentācija ļauj paziņot dizainu citām organizācijas ieinteresētajām pusēm un saņemt viņu atsauksmes. Jūs varat izlaist specifikāciju, sasaukt projekta pārskata sanāksmi un pēc tam sanāksmē prezentēt sistēmas dizainu. Grupa var apspriest jūsu dizainu un, cerams, atrast problēmas un sniegt ieteikumus. Atgriezeniskās saites iegūšana un atgriezeniskās saites rezultātā sistēmas dizaina pielāgošana ir iterācijas piemērs programmatūras izstrādes procesā.
Lietotāja saskarnes prototipu veidošana
Lietotāja saskarnes prototipa izveide projektēšanas posmā bieži ir vērtīga darbība. Kad lietotāja saskarnes prototips ir pabeigts, puses, kas piekritušas specifikācijai, var atkal pulcēties, lai pārskatītu priekšskatījuma versiju. Prototipa iegūšana dod pusēm vēl vienu iespēju vizualizēt un apspriest gala mērķi. Liekot visiem, kas piekrīt specifikācijai, pārskatīt un parakstīties uz lietotāja saskarnes prototipu, jūs palīdzat nodrošināt, ka visām pusēm ir savietojamas cerības attiecībā uz gala produktu. Izmantojot mūsdienās pieejamos vizuālos rīkus uz Java balstītu lietotāju saskarņu izstrādei, lietotāja interfeisa prototipa izstrāde var būt ļoti ātra, un gala rezultāts ir Java koda ietvars, kuru pēc tam jūs varat apveltīt ar funkcionalitāti ieviešanas posmā.
Ņemiet vērā, ka lietotāja saskarnes prototipa demonstrēšanas process ir galvenais attīstības procesa iteratīvā rakstura piemērs. Kad ieinteresētās puses (kuras visas ir vienojušās par rakstisku specifikāciju) faktiski redz lietotāja saskarnes prototipus, tām bieži ir jaunas idejas, labāka izpratne vai detalizētāka izpratne - citiem vārdiem sakot, skaidrāka vīzija - par beigām produktu. Demonstrācijas laikā specifikācijā var tikt veiktas dažas korekcijas. Tomēr cerams, ka līdz šim laikam korekcijas būs nelielas.
Veicot objektorientētu dizainu
Veidojot Java programmu, jums ir jādomā par visām Java valodas piedāvātajām programmēšanas tehnoloģijām, ieskaitot daudzsavienojumu, atkritumu savākšanu, strukturētu kļūdu apstrādi un objektu orientāciju. Tā kā Java programmēšanas valodas dominējošā arhitektūras iezīme ir orientācija uz objektu, Java programmas projektēšanas fāze būtībā ir objektorientētas projektēšanas process.
Objektorientēta dizaina veikšana ietver mantojuma hierarhiju izveidi un atsevišķu klašu un saskarņu lauku un metožu izstrādi. Trīs pamatklases, kuras jūs nāks klajā ar dizainu, ir:
- Lietotāja saskarnes klases
- Problēmas domēnu klases
- Datu pārvaldības klases
Lietotāja saskarnes klases ir tie, kas veido programmas lietotāja saskarni, piemēram, klases, kas attēlo logus un dialoglodziņus. Problēmas domēnu klases ir tie, kas attēlo objektus, kurus esat identificējis problemātiskajā domēnā. Piemēram, ja jūsu problēmu domēnā ir lifti, jums, iespējams, ir Lifts klase jūsu risinājuma domēnā. Datu pārvaldības klases ir tie, kurus izveidojat, lai pārvaldītu objektus vai datus. Ne lietotāja saskarnes klasēs, ne datu pārvaldības klasēs problēmu domēnā nav atbilstošu objektu.
3. posms: ieviešana
Ieviešana ir kodēšana. Rakstīšana cilpām, ja paziņojumi, nozvejas klauzulas, mainīgie un komentāri; sastādīšana; vienības testēšana; kļūdu labošana - tā ir ieviešana: stingra programmēšanas darbība.
4. fāze: integrācija un pārbaude
Integrācijas un testēšanas posmā projekta komandas locekļi, kuru uzdevums ir izveidot noteiktu kopuma daļu, tiekas un mēģina panākt, lai visi programmatūras sistēmas elementi darbotos kopā. Šajā posmā komandas locekļi uzzina, cik labi saskarnes starp atsevišķiem sistēmas komponentiem tika definētas un sazinātas sistēmas nodalīšanas posmā. Šajā fāzē notiekošajai kodēšanai galvenokārt vajadzētu būt kļūdu labošanai.
Programmatūras dizaina dokumentēšana
Programmatūras projektēšanai ir daudz pieeju. Oficiālās metodoloģijas mēģina jūs novirzīt problēmu domēna pārveidošanas procesā par risinājuma domēnu. Veidojot Java programmas, jūs varat izvēlēties izmantot formālu metodiku, apvienot vairākas formālas metodikas vai atteikties no formālās metodikas un dizaina pie biksēm. Lai arī kā jūs uzbrūkat programmatūras projekta projektēšanas fāzei, jums kaut kādā veidā vajadzētu dokumentēt savu dizainu.
