Runājot par labu OO dizainu, saglabājiet to vienkārši

Kāds mans bijušais students reiz izplūda pretrunīgo paziņojumu: "Es, iespējams, nevaru veikt objektorientētu (OO) dizainu; man nav naudas!" Turpmāk uzzinot, izrādījās, ka, pēc viņa domām, OO dizainam bija nepieciešams produkts ar nosaukumu Rational Rose, kas tajā laikā maksāja apmēram 500,00 par vietu. Viņaprāt, bez Rational Rose dizains nebija iespējams. Diemžēl šāda veida balderdash ir plaši izplatīta; pārāk daudzi cilvēki domā, ka OO ir augsto tehnoloģiju process, kam nepieciešami augsto tehnoloģiju rīki. Praksē par pārmērīgi augstu cenu instrumenti tiek neizmantoti plauktā (vai arī tie tiek nepietiekami izmantoti).

Paturot to prātā, šajā rakstā es apspriedu dažādus OO dizaina rīkus, to darbību un kāpēc, manuprāt, tie nav noderīgi. Es arī izskaidroju, kā es strādāju, un kas izrādās noderīgs (vismaz man; jūs varat nepiekrist).

Rīki neievada jūs procesā

Katrs veiksmīgais OO dizains, ar kuru esmu nācis, ir apmēram tāds pats:

Uzziniet par problēmu domēns (grāmatvedība, stundu plānošana utt.)
Cieši sadarbojoties ar tiešraides lietotāju, izstrādājiet a problēmas izklāsts kas izsmeļoši apraksta lietotāja problēmu, kā arī visus domēna līmeņa risinājumus. Šajā dokumentā nav aprakstīta datorprogramma.
Veic oficiālu lietošanas gadījumu analīze, kurā es nosaku uzdevumus, kas nepieciešami lietotāja problēmas risināšanai, atkal cieši sadarbojoties ar reālu galalietotāju. Parasti es izveidoju UML (vienoto modelēšanas valodu) aktivitātes diagramma katram neaktīvam lietošanas gadījumam. (UML ir programmatūras kā attēla simbolisks attēlojums.)
Sāciet veidot dinamisks modelis parādot sistēmā esošos objektus un ziņojumus, kurus šie objekti sūta viens otram, kamēr tiek rīkots konkrēts lietošanas gadījums. Es izmantoju UML secības diagramma šim nolūkam.
Es vienlaikus uztveru noderīgu informāciju vietnē statiskais modelis diagramma. Piezīme: Es nekad vispirms neizveidoju statisko modeli (klases diagrammu). Es esmu izmetis pārāk daudz statisku modeļu, kas izrādījās bezjēdzīgi, tiklīdz sāku darīt dinamisko modeli. Es vairs nevēlos tērēt laiku, kas vajadzīgs statiskā modeļa veikšanai vakuumā.
Iepriekš minētās darbības parasti rada divus vai trīs lietošanas gadījumus, pēc kuriem es sāku kodēšanu, vajadzības gadījumā salabojot modeli.
Visbeidzot, es strādāju pie cita lietojuma, kā aprakstīts, pēc nepieciešamības pārstrādājot dizainu un kodu, lai pielāgotos jaunajam gadījumam.

Neviens no mūsdienu dizaina rīkiem neievada jūs šajā procesā. Pārsvarā tās ir pārcenotas zīmēšanas programmas, kas nedarbojas īpaši labi, pat kā zīmēšanas rīki. (Rational Rose, kuru es uzskatu par vienu no vismazāk spējīgajām partijai, pat neatbalsta visu UML.)

Inženierzinātnes turp un atpakaļ ir principiāli kļūdains process

Šie rīki ne tikai nedarbojas labi, bet viens triks, ko šie rīki veic - ģenerē kodu - ir nevērtīgs. Gandrīz visi OO dizaina rīki atbilst jēdzienam turp un atpakaļ inženierija kurā jūs sākat dizaina rīkā, norādot savu dizainu UML. Jūs izveidojat divas būtiskas diagrammu kopas: statisko modeli, kas parāda dizaina klases, to savstarpējās attiecības un tajās esošās metodes; un dinamiskais modelis, kas ir diagrammu kaudze, kas parāda sistēmas objektus, izpildes laikā veicot dažādus uzdevumus.

Kad esat pabeidzis modeli, jūs nospiežat burvju pogu, un rīks ģenerē kodu. Tomēr rīku radītais kods nav īpaši labs divu iemeslu dēļ: Pirmkārt, daudzos rīkos tiek izveidoti klases definīciju skeleti, bet metodes ir vienkārši tukšas vietas - dinamiskais modelis tiek ignorēts. Otrkārt, neviens rīks pilnībā neatbalsta UML, galvenokārt tāpēc, ka neviens nevar. UML ir pati sava valoda, kas veicina improvizāciju, un liela daļa faktiskā dizaina satura tiek izteikta komentāros, kurus parasti ignorē dizaina rīks.

Rezultātā jūs uzlaužat izveidoto kodu (lielākā daļa veikalu to patiešām uzlauž). Dažu nedēļu laikā kodam parasti ir maz vai nav nekā kopīga ar sākotnējo dizainu. Patiesībā jūs efektīvi izmetat savu dizainu un atkal nonākat WHISKEY sindromā (Kāpēc kāds vēl nav "kodēts"?). Gadiem un gadiem neizdevušās programmas man pierāda, ka kodēšana bez dizaina kopējo izstrādes laiku palielina vismaz par trīs reizes un rada daudz kļūdaināku kodu.

Tagad nāk turp un atpakaļ process: jūs atverat savu rīku, nospiežat burvju pogu un importējat kodu, teorētiski pārbūvējot dizainu tā, lai tas atspoguļotu koda faktisko stāvokli. Šāda reversā inženierija tomēr nedarbojas. Rīki parasti izveido jaunas klases diagrammas, bet nekad neatjaunina dinamisko modeli. Tā kā dinamiskajam modelim ir galvenā nozīme šajā procesā, jūsu dizains tagad ir bezvērtīgs, ja vien neatgriežaties un neatjaunojat to ar roku, kaut kas reti izdarīts.

Risks atkārtoties, turp un atpakaļ process mudina programmētājus pilnībā neņemt vērā dizainu un vienkārši kodēt, pēc tam kodu pārveidot attēlos tik bieži. Šajā situācijā programmētāji tomēr neveido projektēšanu; viņi uzlauž kodu, pēc tam izveidojot iegūtā jucekļa attēlus. Datorurķēšana nav vienāda ar dizainu.

Lai gan dizains patiešām ir iteratīvs process (dizains mainās, izstrādājot kodu), jums vajadzētu sākt iterāciju, vispirms modificējot dizainu, pēc tam pārveidojot kodu, lai tas atspoguļotu jauno dizainu. Lai to izdarītu, rīkā ir jāspēj norādīt visu programmatūras produktu (nospiežot burvju pogu, tiks izvadīta pilnībā funkcionējoša programma), un process būtu vienvirziena bez reversās inženierijas. mehānisms.

Rīki CASE

Tādi CASE (datorizēta programmatūras inženierija) rīki kā Rational Rose parasti produkta pamatā ir abpusēja inženierija. Tomēr, tā kā turp un atpakaļ inženierija nedara neko noderīgu, daudzi izstrādātāji izmanto rīkus kā dārgas zīmēšanas programmas. No pieejamajiem rīkiem, manuprāt, ir vērts apsvērt trīs (lai gan nevienu no tiem neizmantoju):

Bezmaksas, atvērtā koda ArgoUML rīks, kas rakstīts Java valodā, veic samērā labu darbu UML diagrammās. Jaunākajā versijā jūs pat mēģināt iepazīstināt ar procesu (līdz šim ar nelieliem panākumiem, taču tas ir labs sākums).
Embarcadero GDPro, ko iepriekš izplatīja Advanced Software, piedāvā labu atbalstu grupai, kas strādā pie viena programmatūras dizaina, taču tajā ir arī trūkumi. Piemēram, dizainers nevar pārbaudīt dinamiskā modeļa diagrammu, vienlaikus automātiski bloķējot klases, kas saistītas ar objektiem dinamiskajā modelī.
TogetherSoft Together ControlCenter apiet apgrieztā brauciena problēmu, to nedarot. Ekrānā vienlaicīgi tiek parādīts kods un noformējums, un, mainot vienu, otrs mainās automātiski. ControlCenter tomēr labi neatbalsta programmētāju grupas.
Man īsi jāpiemin arī Microsoft Visio. Visio ir zīmēšanas programma, kas pēc modeļa atbalsta UML, taču tās atbalsts atdarina Rational Rose nožēlojamo lietotāja interfeisu. Dažādas zīmējumu veidnes UML formām Visio darbojas labāk nekā iebūvētais UML atbalsts, ieskaitot vienu no manas vietnes sadaļas “Labumi”.

Tātad, ja es tik slikti domāju par šiem rīkiem, ko es izmantoju? Pārsvarā visproduktīvākie OO dizaina rīki ir tāfele (ideāli piemērota telpa ar sienām pie sienas, tāfelēm no grīdas līdz griestiem) un flip-chart izmēra Post-it spilventiņi, kuru loksnes var nolobīt nūju pie sienas. Es tos izmantoju, lai ar lieliem panākumiem izstrādātu nozīmīgus projektus. Turklāt darbs pie tāfeles patērē daudz mazāk laika nekā cīņa ar OO CASE rīku.

Vienīgās grūtības ar tāfeles pieeju ir informācijas uztveršana uz tāfeles. Drukājamās tāfeles pastāv, taču tās ir dārgas, neizdevīgas un pārāk mazas. Viens veikls aparatūras izstrādājums, kas izseko pildspalvas kustību pa tāfeli un uztver pildspalvas sitienus datorā. Citas tāfeles darbojas kā milzu digitalizēšanas tabletes. Tomēr šie risinājumi izrādās pārāk ierobežojoši; dizains vienlaikus notiek uz tāfelēm vairākos birojos, uz salvetēm, uz papīra atgriezumiem un tā tālāk. Jūs nevarat nest 300 mārciņu drukas tāfeli uz vietējo kafejnīcu.

Tātad, kas darbojas

Ko tad darīt mātei? Kā jūs sagūstāt šos artefaktus, lai tos arhivētu datorā, lai viņi sagatavotu saprātīgu dokumentāciju, kāda tā ir, nepārsūtot tos uz zīmēšanas programmu?

Atrisinājums:

Digitālā kamera
Brīnišķīgs programmatūras izstrādājums ar nosaukumu Pixid Whiteboard Photo

Diemžēl digitālais fotoattēls bieži rada neapmierinošus attēlus dokumentēšanai. Lai to kompensētu, Whiteboard Photo pārveido digitālos attēlus par kaut ko noderīgu. Bildes tiešām ir tūkstoš vārdu vērtas. 1. attēlā parādīta tipiska tāfeles digitālā fotogrāfija.

2. attēlā parādīts vēl viens piemērs.

3. attēlā parādīts, kā Whiteboard Photo pārveido 1. attēlu.

Lūk, kā 2. attēls izskatās pēc tāfeles fotoattēla burvības.

Kā rāda attēli, atšķirība ir pārsteidzoša. Lai pārveidotu oriģinālo attēlu iztīrītajā versijā, es vienkārši trāpīju Ctrl-L. Programmatūra automātiski atrada tāfeles robežas, koriģēja traucējumus, ko radīja attēla uzņemšana no leņķa (nepieciešams, lai izvairītos no zibspuldzes atspīdumiem), izvēlējās dizaina līnijas un uzzīmēja tās. Viss, kas produktam nepieciešams, lai sasniegtu pilnību, ir roku rakstīšanas atpazīšana, bet es ar to esmu sārtā formā, kā tas ir. Tagad es varu izgatavot dokumentācijas kvalitātes rasējumus tieši no oriģinālās tāfeles, netērējot stundas, zīmējumu ieviešot kādā klibā attaisnojumā CASE rīkam.

Atstāj to vienkāršu

Pēc manas pieredzes, runājot par OO dizainu, vislabāk darbojas zemu tehnoloģiju rīki. Patiešām, tie ir ātrāki, vieglāk lietojami un labi darbojas sadarbības vidēs. Līdz šim esmu atklājis, ka tāfeles, digitālās fotokameras un tāfeles fotoattēlu kombinācija piedāvā vislabāko metodi programmu noformējuma iegūšanai mašīnā.

Alens Holubs sniedz konsultāciju pakalpojumus, apmācību un mentoringu OO projektēšanā, OO procesā un Java programmēšanā. Viņš regulāri piedāvā intensīvu OO dizaina darbnīcu tiem, kas vēlas ātri attīstīt savas OO prasmes. (Atrodiet vairāk informācijas vietnē //www.holub.com.) Allens kopš 1979. gada ir strādājis datoru nozarē, pēdējais ir NetReliance, Inc. galvenais tehnoloģiju vadītājs. Viņš ir plaši publicēts žurnālos (Dr. Dobb's Journal, Programmers Journal, (Starp citu, baits un MSJ). Alena godā ir astoņas grāmatas, no kurām jaunākā - Taming Java Threads (APpress, 2000; ISBN: 1893115100) - aptver Java pavedienu slazdus un slazdus. Viņš pasniedz OO dizainu un Java Kalifornijas Universitātē Berkeley Extension (kopš 1982. gada).

Uzziniet vairāk par šo tēmu

Lai iegūtu bezmaksas, atvērtā koda ArgoUML dizaina rīku, dodieties uz
//argouml.tigris.org/
Embarcadero GDPro var atrast vietnē
//www.embarcadero.com
Plašāku informāciju atradīsit vietnē TogetherSoft Together ControlCenter vietnē
//www.togethersoft.com
Microsoft Visio mājas lapa
//www.microsoft.com/office/visio/default.htm
Dodieties uz produkta Pixid Whiteboard Photo lapu, lai iegūtu plašāku informāciju par šo interesanto rīku
//www.pixid.com/home.html
Alena Holuba vietnē ir viņa lapa "Labumi", kurā atradīsit OO dizaina padomus, īkšķa programmēšanas noteikumus un piezīmes no dažām Alena sarunām
//www.holub.com/goodies/goodies.html
JavaWorld's Uz objektu orientēta projektēšana un programmēšana Indeksā ir daudz rakstu par dizainu
//www.javaworld.com/channel_content/jw-oop-index.shtml
Jūs atradīsit vairāk lielisku produktu pārskatu JavaWorld's Produktu atsauksmju indekss
//www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml
Vairāk komentāru lasiet JavaWorld's Komentāru rādītājs
//www.javaworld.com/news-reviews/jw-nr-commentary.shtml
Lai saņemtu padomus un konsultācijas par dizaina modeļiem, izstrādes rīkiem, veiktspējas regulēšanu, drošību, testēšanu un citu, reģistrējieties mūsu vietnē Lietojumprogramma Java biļetens
//www.javaworld.com/subscribe
Runājiet mūsu Programmēšanas teorija un prakse diskusija
//forums.idg.net/webx?50@@.ee6b806
Jūs atradīsit daudz ar IT saistītu rakstu no mūsu māsas publikācijām vietnē .net