Programavimas

Kalbant apie gerą OO dizainą, būkite paprastas

Mano buvęs studentas kartą išpūtė priešišką teiginį: "Aš niekaip negaliu kurti objektinio (OO) dizaino; neturiu pinigų!" Pasiteiravus paaiškėjo, kad, jo nuomone, OO dizainui reikalingas produktas „Rational Rose“, kuris tuo metu kainavo apie 500,00 už vietą. Jo nuomone, be „Rational Rose“ dizainas nebuvo įmanomas. Deja, toks balderdashas yra plačiai paplitęs; per daug žmonių mano, kad OO yra aukštųjų technologijų procesas, reikalaujantis aukštųjų technologijų įrankių. Praktiškai neįkainojamos kainos įrankiai sėdi nenaudojami lentynoje (arba yra labai nepakankamai naudojami).

Atsižvelgdamas į tai, šiame straipsnyje aptariu įvairius OO projektavimo įrankius, kaip jie veikia ir kodėl manau, kad jie nėra naudingi. Aš taip pat paaiškinu, kaip aš dirbu ir kas pasirodo naudinga (bent jau man; galite nesutikti).

Įrankiai neveda jūsų per procesą

Kiekvienas mano sukurtas sėkmingas OO dizainas vyko maždaug tuo pačiu procesu:

  • Sužinokite apie probleminis domenas (apskaita, pamokų planavimas ir kt.)
  • Glaudžiai konsultuodamasis su tiesioginiu vartotoju, sukurkite a problemos pareiškimas išsamiai apibūdina vartotojo problemą ir visus domeno lygio sprendimus. Šiame dokumente neapibūdinama kompiuterinė programa.
  • Atlikite oficialų naudojimo atvejo analizė, nustatydamas užduotis, reikalingas vartotojo problemai išspręsti, vėl glaudžiai bendradarbiaudamas su tikruoju galutiniu vartotoju. Paprastai kuriu UML (vieningą modeliavimo kalbą) veiklos diagrama kiekvienam nereikšmingam naudojimo atvejui. (UML yra simbolinis programinės įrangos vaizdas.)
  • Pradėkite kurti dinamiškas modelis rodomi sistemos objektai ir pranešimai, kuriuos tie objektai siunčia vienas kitam, kol vykdomas konkretus naudojimo atvejis. Aš naudoju UML sekos schema šiam tikslui.
  • Aš tuo pačiu metu užfiksuoju naudingą informaciją apie statinis-modelis schema. Pastaba: Aš niekada nedarau statinio modelio (klasės diagramos) pirmiausia. Išmetiau per daug statinių modelių, kurie pasirodė nenaudingi, kai tik pradėjau daryti dinaminį modelį. Nebenoriu gaišti laiko, reikalingo statiniam modeliui atlikti vakuume.
  • Pirmiau minėti žingsniai paprastai duoda du ar tris naudojimo atvejus, po kurių aš pradedu koduoti, prireikus pataisydamas modelį.
  • Galiausiai, aš dirbu prie kito naudojimo atvejo, kaip aprašyta, pertvarkydamas dizainą ir kodą, jei reikia, kad pritaikytumėte naują atvejį.

Nė vienas iš šiandieninių projektavimo įrankių neveda šio proceso. Dažniausiai tai yra per brangios piešimo programos, kurios neveikia ypač gerai, net kaip piešimo priemonės. („Rational Rose“, kuri, mano manymu, yra mažiausiai pajėgi iš partijos, net nepalaiko viso UML.)

Inžinerija pirmyn ir atgal yra iš esmės ydingas procesas

Šios priemonės ne tik neveikia gerai, bet ir vienas triukas, kurį atlieka šie įrankiai - kodo generavimas - yra bevertis. Beveik visos OO projektavimo priemonės atitinka sąvoką inžinerija pirmyn ir atgal kuriame pradedate dizaino įrankį nurodydami savo dizainą UML. Sukuriate du esminius diagramų rinkinius: statinį modelį, kuriame parodomos dizaino klasės, jų tarpusavio santykiai ir juose esantys metodai; ir dinaminis modelis, tai yra diagramų krūva, rodanti sistemos objektus, vykdymo metu atliekančius įvairias užduotis.

Užbaigus modelį, paspausite stebuklingą mygtuką ir įrankis sugeneruos kodą. Tačiau įrankių sugeneruotas kodas nėra ypač geras dėl dviejų priežasčių: Pirma, daugelyje įrankių kuriami klasių apibrėžimų griaučiai, tačiau metodai yra tiesiog tušti kamščiai - dinaminis modelis nepaisomas. Antra, jokie įrankiai visiškai nepalaiko UML, visų pirma todėl, kad nė vienas negali. UML yra savarankiška kalba, skatinanti improvizuoti, ir didžioji dalis tikrojo dizaino turinio išreiškiama komentarais, kurių paprastai nepaiso dizaino įrankis.

Todėl jūs nulaužiate sugeneruotą kodą (dauguma parduotuvių jį tikrai nulaužia). Per kelias savaites kodas paprastai neturi nieko bendro su originaliu dizainu. Tiesą sakant, jūs veiksmingai išmeskite savo dizainą ir vėl pateksite į WHISKEY sindromą (kodėl dar niekas „neužkoduoja“?). Metai ir metai nesėkmingų programų man įrodo, kad kodavimas be dizaino padidina bendrą kūrimo laiką bent tris kartus ir suteikia daug klaidingesnį kodą.

Dabar ateina pirmyn ir atgal procesas: atidarote savo įrankį, paspaudžiate stebuklingą mygtuką ir importuojate kodą, teoriškai pertvarkydami dizainą taip, kad jis atspindėtų tikrąją kodo būseną. Tačiau tokia atvirkštinė inžinerija neveikia. Įrankiai paprastai kuria naujas klasių diagramas, tačiau niekada neatnaujina dinaminio modelio. Kadangi dinaminis modelis yra svarbiausias procesas, jūsų dizainas dabar yra nieko vertas, nebent grįšite atgal ir atnaujinsite jį rankomis, o tai daroma retai.

Rizikuodamas pasikartoti, pirmyn ir atgal procesas skatina programuotojus visiškai nepaisyti dizaino ir tiesiog koduoti, tada pakeisti kodą į paveikslėlius taip dažnai. Tačiau šioje situacijoje programuotojai ne projektuoja; jie įsilaužia kodą, tada sukuria susidariusios netvarkos nuotraukas. Įsilaužimas neprilygsta dizainui.

Nors dizainas iš tikrųjų yra iteracinis procesas (dizainas keičiasi kuriant kodą), turėtumėte pradėti iteraciją pirmiausia modifikuodami dizainą, tada pertvarkydami kodą, kad jis atspindėtų naują dizainą. Norėdami tai padaryti, turite sugebėti įrankyje nurodyti visą programinės įrangos produktą (paspaudus magišką mygtuką, bus išvestas visiškai veikiantis programa), o procesas būtų vienpusis be atvirkštinės inžinerijos mechanizmas.

CASE įrankiai

Tokie „CASE“ (kompiuterinės programinės įrangos inžinerijos) įrankiai, kaip „Rational Rose“, paprastai teikia produkto inžineriją pirmyn ir atgal. Tačiau kadangi inžinerija pirmyn ir atgal nieko naudingo nedaro, daugelis kūrėjų įrankius naudoja kaip brangias piešimo programas. Iš turimų įrankių, manau, verta apsvarstyti tris (nors nė vieno jų nenaudoju):

  • Nemokamas, atviro kodo „ArgoUML“ įrankis, parašytas „Java“, pakankamai gerai atlieka UML diagramų darbą. Naujausia versija net bando jus aptarti procesą (kol kas nežymiai sėkmingai, tačiau tai gera pradžia).
  • „Embarcadero“ „GDPro“, kurį anksčiau platino „Advanced Software“, siūlo gerą paramą grupei, kuriančiai vieną programinės įrangos dizainą, tačiau taip pat turi trūkumų šiame skyriuje. Pvz., Dizaineris negali patikrinti dinaminio modelio diagramos, automatiškai užrakindamas klases, susietas su objektais dinaminiame modelyje.
  • „TogetherSoft“ „Together ControlCenter“ apeina atbulinės eigos problemą to nedarydamas. Kodas ir dizainas ekrane pasirodo vienu metu, o pakeitus vieną, kitas pasikeičia automatiškai. Vis dėlto „ControlCenter“ gerai nepalaiko programuotojų grupių.
  • Taip pat turėčiau trumpai paminėti „Microsoft“ „Visio“. „Visio“ yra piešimo programa, kuri pagal madą palaiko UML, tačiau jos pagalba imituojama apgailėtina Rational Rose vartotojo sąsaja. Įvairūs „Visio“ UML formų piešimo šablonai veikia geriau nei įmontuotas UML palaikymas, įskaitant vieną mano svetainės skiltyje „Gėrybės“.

Taigi, jei aš taip prastai galvoju apie šias priemones, ką aš naudoju? Labiausiai produktyviausi OO dizaino įrankiai yra lenta (idealiai tinka patalpa su lentomis nuo sienos iki sienos, nuo grindų iki lubų) ir lentos dydžio „Post-it“ pagalvėlės, kurių lapus galite nulupti ir klijuoti ant sienos. Aš juos panaudojau kurdamas reikšmingus projektus, labai sėkmingai. Be to, dirbant prie lentos sugaišta kur kas mažiau laiko nei imtynių su OO CASE įrankiu.

Vienintelis požiūris į lentą yra informacijos užfiksavimas lentoje. Spausdinimo lentos egzistuoja, bet jos brangios, nepatogios ir per mažos. Vienas tvarkingas aparatūros gaminys, stebintis rašiklio judėjimą per lentą ir fiksuojantis rašiklio smūgius kompiuteryje. Kitos lentos veikia kaip milžiniškos skaitmeninimo tabletės. Tačiau šie sprendimai yra pernelyg ribojantys; dizainas vienu metu vyksta ant lentų keliuose biuruose, ant servetėlių, ant popieriaus likučių ir pan. Negalite nešti 300 svarų spausdinimo lentos į vietinę kavinę.

Taigi, kas veikia

Taigi, ką daryti motinai? Kaip užfiksuoti šiuos artefaktus, kad archyvuotumėte juos kompiuteryje, kad jie padarytų pagrįstus dokumentus, kokie jie yra, be jų perkelti į piešimo programą?

Sprendimas:

  1. Skaitmeninis fotoaparatas
  2. Nuostabus programinės įrangos produktas „Pixboard Photo Whiteboard Photo“

Deja, dėl skaitmeninės nuotraukos dažnai gaunami vaizdai, kurie nėra patenkinami dokumentacijai. Norėdami kompensuoti, „Whiteboard Photo“ paverčia skaitmenines nuotraukas naudingomis. Nuotraukos tikrai vertos tūkstančio žodžių. 1 paveiksle parodyta tipinė skaitmeninė lentos nuotrauka.

2 paveiksle pavaizduotas kitas pavyzdys.

3 paveiksle parodyta, kaip „Whiteboard Photo“ transformuoja 1 paveikslą.

Štai kaip 2 paveikslas atrodo, kai „Whiteboard Photo“ padarė savo kerą.

Kaip rodo vaizdai, skirtumas yra nuostabus. Norėdami pakeisti originalų vaizdą į išvalytą versiją, aš tiesiog pataikiau „Ctrl-L“. Programinė įranga automatiškai nustatė lentos ribas, pakoregavo iškraipymus, padarytus fotografuojant iš kampo (būtina, kad būtų išvengta blykstės atspindžio), išrinko dizaino linijas ir jas nupiešė. Viskas, ko reikia norint, kad produktas būtų tobulas, yra ranka atpažįstamas ranka, bet aš toks, koks jis yra, rožinis. Dabar aš galiu pagaminti dokumentacijos kokybės brėžinius tiesiai iš originalios lentos, negaišdamas valandų, įvesdamas piešinį į kažkokį klibų pasiteisinimą CASE įrankiui.

Daryk paprastai

Mano patirtis rodo, kad kalbant apie OO dizainą, geriausiai veikia žemų technologijų įrankiai. Iš tiesų, jie yra greitesni, lengviau naudojami ir puikiai veikia bendradarbiaujant. Iki šiol pastebėjau, kad lentos, skaitmeninio fotoaparato ir „Whiteboard Photo“ derinys yra geriausias būdas gauti programos dizainą į mašiną.

Allenas Holubas teikia konsultavimo paslaugas, mokymus ir konsultacijas OO projektavimo, OO proceso ir „Java“ programavimo srityse. Jis reguliariai pristato intensyvius OO dizaino seminarus tiems, kurie nori greitai tobulinti savo OO įgūdžius. (Daugiau informacijos rasite //www.holub.com.) Allenas nuo 1979 m. Dirbo kompiuterių pramonėje, pastaruoju metu - „NetReliance, Inc.“ vyriausiasis technologijų pareigūnas. Jis yra plačiai publikuojamas žurnaluose (Dr. Dobb's Journal, Programmers Journal, Be to, baitas ir MSJ). Allenas turi savo aštuonias knygas, iš kurių naujausia - „Taming Java Threads“ (APpress, 2000; ISBN: 1893115100) - apima „Java“ siūlų spąstus ir spąstus. Jis dėsto OO dizainą ir „Java“ Kalifornijos universitete, Berkeley Extension (nuo 1982).

Sužinokite daugiau apie šią temą

  • Norėdami rasti nemokamą atvirojo kodo „ArgoUML“ dizaino įrankį, eikite į

    //argouml.tigris.org/

  • „Embarcadero“ GDPro galite rasti adresu

    //www.embarcadero.com

  • Daugiau informacijos rasite „TogetherSoft“ „Together ControlCenter“ svetainėje

    //www.togethersoft.com

  • „Microsoft Visio“ pagrindinis puslapis

    //www.microsoft.com/office/visio/default.htm

  • Norėdami gauti daugiau informacijos apie šį įdomų įrankį, eikite į „Pixid Whiteboard Photo“ produkto puslapį

    //www.pixid.com/home.html

  • Alleno Holubo svetainėje yra jo puslapis „Gėrybės“, kuriame rasite OO dizaino patarimus, programavimo taisykles ir pastabas iš kai kurių Alleno pokalbių

    //www.holub.com/goodies/goodies.html

  • „JavaWorld“'s Objektinis projektavimas ir programavimas Rodyklėje yra daugybė straipsnių, skirtų dizainui

    //www.javaworld.com/channel_content/jw-oop-index.shtml

  • Čia rasite daugiau puikių produktų apžvalgų „JavaWorld“'s Produktų apžvalgų indeksas

    //www.javaworld.com/news-reviews/jw-nr-product-reviews.shtml

  • Daugiau komentarų skaitykite „JavaWorld“'s Komentarų rodyklė

    //www.javaworld.com/news-reviews/jw-nr-commentary.shtml

  • Norėdami gauti patarimų ir pamokymų apie dizaino modelius, kūrimo įrankius, našumo derinimą, saugumą, testavimą ir dar daugiau, prisiregistruokite mūsų svetainėje Taikoma „Java“ naujienlaiškis

    //www.javaworld.com/subscribe

  • Kalbėk mūsų Programavimo teorija ir praktika diskusija

    //forums.idg.net/webx?50@@.ee6b806

  • Rasite daugybę su IT susijusių straipsnių iš mūsų seserų leidinių .net

Šią istoriją „Kalbant apie gerą OO dizainą, būk paprastas“ iš pradžių išleido „JavaWorld“.

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