vat' neudachu. Nuzhno imet'
organizaciyu i strategiyu razvitiya programmnogo obespecheniya, kotorye
naceleny na sozdanie i podderzhanie mnogih versij raznyh sistem, t.e.
nuzhno mnogokratnoe planirovanie uspeha.
    Cel' proektirovaniya v vyrabotke yasnoj i otnositel'no prostoj
vnutrennej struktury programmy, nazyvaemoj inogda arhitekturoj, inymi
slovami karkasa, v kotoryj ukladyvayutsya otdel'nye programmnye fragmenty,
i kotoryj pomogaet napisaniyu etih fragmentov.
   Proekt - konechnyj rezul'tat processa proektirovaniya (esli tol'ko
byvaet konechnyj produkt u iterativnogo processa). On yavlyaetsya
sredotochiem vzaimodejstvij mezhdu razrabotchikom i programmistom i
mezhdu programmistami. Zdes' neobhodimo soblyusti chuvstvo mery. Esli ya,
kak otdel'nyj programmist, proektiruyu nebol'shuyu programmu, kotoruyu
sobirayus' napisat' zavtra, to tochnost' i polnota opisaniya proekta
mozhet svestis' k neskol'kim karakulyam na obratnoj storone konverta.
Na drugom polyuse nahoditsya sistema, nad kotoroj rabotayut sotni
programmistov i razrabotchikov, i zdes' mogut potrebovat'sya toma
tshchatel'no sostavlennyh specifikacij proekta na formal'nom ili
poluformal'nom yazyke. Opredelenie nuzhnoj stepeni tochnosti, detalizacii
i formal'nosti proektirovaniya yavlyaetsya uzhe samo po sebe netrivial'noj
tehnicheskoj i administrativnoj zadachej.
   Dalee budet predpolagat'sya, chto proekt sistemy zapisyvaetsya
kak ryad opredelenij klassov (v kotoryh chastnye opisaniya opushcheny
kak lishnie detali) i vzaimootnoshenij mezhdu nimi. |to uproshchenie, t.k.
konkretnyj proekt mozhet uchityvat': voprosy parallel'nosti, ispol'zovanie
global'nogo prostranstva imen, ispol'zovanie global'nyh funkcij i
dannyh, postroenie programmy dlya minimizacii peretranslyacii,
ustojchivost', mnogomashinnyj rezhim i t.p. No pri obsuzhdenii na dannom
urovne detalizacii bez uproshcheniya ne obojtis', a klassy v kontekste S++
yavlyayutsya klyuchevym ponyatiem proektirovaniya. Nekotorye iz ukazannyh
voprosov budut obsuzhdat'sya nizhe, a te, kotorye pryamo zatragivayut
proektirovanie bibliotek S++, budut rassmotreny v glave 13. Bolee
podrobnoe obsuzhdenie i primery opredelennyh metodov ob容ktno-
orientirovannogo proektirovaniya soderzhatsya v [2].
    My soznatel'no ne provodili chetkogo razdeleniya analiza i
proektirovaniya, poskol'ku obsuzhdenie ih razlichij vyhodit za ramki etoj
knigi, i ono zavisit ot primenyaemyh metodov proektirovaniya. Glavnoe v tom,
chtoby vybrat' metod analiza, podhodyashchij dlya metoda proektirovaniya, i
vybrat' metod proektirovaniya, podhodyashchij dlya stilya programmirovaniya
i ispol'zuemogo yazyka.

        11.3 Process razvitiya

Process razvitiya programmnogo obespecheniya - eto iterativnyj i
rasshiryayushchijsya process. Po mere razvitiya kazhdaya stadiya povtoryaetsya
mnogokratno, i pri vsyakom vozvrate na nekotoruyu stadiyu processa utochnyaetsya
konechnyj produkt, poluchaemyj na etoj stadii. V obshchem sluchae process
ne imeet ni nachala, ni konca, poskol'ku, proektiruya i realizuya sistemu,
vy nachinaete, ispol'zuya kak bazu drugie proekty, biblioteki i prikladnye
sistemy, v konce raboty posle vas ostaetsya opisanie proekta i programma,
kotorye drugie mogut utochnyat', modificirovat', rasshiryat' i perenosit'.
Estestvenno konkretnyj proekt imeet opredelennoe nachalo i konec, i
vazhno (hotya chasto udivitel'no trudno) chetko i strogo ogranichit' vremya
i oblast' dejstviya proekta. No zayavlenie, chto vy nachinaete s "chistogo
lista", mozhet privesti k ser'eznym problemam dlya vas, takzhe kak i poziciya,
chto posle peredachi okonchatel'noj versii - hot' potop, vyzovet
ser'eznye problemy dlya vashih posledovatelej (ili dlya vas v novoj
roli).
    Iz etogo vytekaet, chto sleduyushchie razdely mozhno chitat' v lyubom
poryadke, poskol'ku voprosy proektirovaniya i realizacii mogut v
real'nom proekte perepletat'sya pochti proizvol'no. Imenno, "proekt"
pochti vsegda podvergaetsya pereproektirovaniyu na osnove predydushchego
proekta, opredelennogo opyta realizacii, ogranichenij, nakladyvaemyh
srokami, masterstvom rabotnikov, voprosami sovmestimosti i t.p.
Zdes' osnovnaya trudnost' dlya menedzhera ili razrabotchika ili
programmista v tom, chtoby sozdat' takoj poryadok v etom processe,
kotoryj ne prepyatstvuet usovershenstvovaniyam i ne zapreshchaet povtornye
prohody, neobhodimye dlya uspeshnogo razvitiya.
   U processa razvitiya tri stadii:
 - Analiz: opredelenie oblasti zadachi.
 - Proektirovanie: sozdanie obshchej struktury sistemy.
 - Realizaciya: programmirovanie i testirovanie.
Ne zabud'te ob iterativnoj prirode etih processov (nesprosta stadii
ne byli pronumerovany), i zamet'te, chto nikakie vazhnye aspekty processa
razvitiya programmy ne vydelyayutsya v otdel'nye stadii, poskol'ku oni
dolzhny dopuskat':
 - |ksperimentirovanie.
 - Testirovanie.
 - Analiz proektirovaniya i realizacii.
 - Dokumentirovanie.
 - Soprovozhdenie.
 Soprovozhdenie programmnogo obespecheniya rassmatrivaetsya prosto kak
 eshche neskol'ko prohodov po stadiyam processa razvitiya (sm. takzhe
$$11.3.6).
   Ochen' vazhno, chtoby analiz, proektirovanie i realizaciya ne byli
slishkom otorvany drug ot druga, i chtoby lyudi, prinimayushchie v nih
uchastie, byli odnogo urovnya kvalifikacii dlya nalazhivaniya effektivnyh
kontaktov.
V bol'shih proektah slishkom chasto byvaet inache. V ideale, v processe
razvitiya proekta rabotniki dolzhny sami perehodit' s odnoj stadii na
druguyu: luchshij sposob peredachi tonkoj informacii - eto ispol'zovat'
golovu rabotnika. K sozhaleniyu, v organizaciyah chasto ustanavlivayut
bar'ery dlya takih perehodov, naprimer, u razrabotchika mozhet byt'
bolee vysokij status i (ili) bolee vysokij oklad, chem u "prostogo"
programmista. Ne prinyato, chtoby sotrudniki hodili po otdelam s cel'yu
nabrat'sya opyta i znanij, no pust', po krajnej mere, budut
regulyarnymi sobesedovaniya sotrudnikov, zanyatyh na raznyh stadiyah proekta.
   Dlya srednih i malyh proektov obychno ne delayut razlichiya mezhdu
analizom i proektirovaniem - eti stadii slivayutsya v odnu. Dlya malyh
proektov takzhe ne razdelyayut proektirovanie i programmirovanie.
Konechno, tem samym reshaetsya problema vzaimodejstviya. Dlya dannogo
proekta vazhno najti podhodyashchuyu stepen' formalizacii i vyderzhat'
nuzhnuyu stepen' razdeleniya mezhdu stadiyami ($$11.4.2). Net edinstvenno
vernogo sposoba dlya etogo.
   Privedennaya zdes' model' processa razvitiya programmnogo obespecheniya
radikal'no otlichaetsya ot tradicionnoj modeli "kaskad" (waterfall).
V poslednej process razvitiya protekaet linejno ot stadii analiza do
stadii testirovaniya. Osnovnoj nedostatok modeli kaskad tot, chto v nej
informaciya dvizhetsya tol'ko v odnom napravlenii. Esli vyyavlena
problema "nizhe po techeniyu", to voznikaet sil'noe metodologicheskoe
i organizacionnoe davlenie, chtoby reshit' problemu na dannom urovne,
ne zatragivaya predydushchih stadij processa. Otsutstvie povtornyh
prohodov privodit k defektnomu proektu, a v rezul'tate lokal'nogo
ustraneniya problem poluchaetsya iskazhennaya realizaciya. V teh
neizbezhnyh sluchayah, kogda informaciya dolzhna byt' peredana nazad k
istochniku ee polucheniya i vyzvat' izmeneniya v proekte, my poluchim
lish' slaboe "kolyhanie" na vseh urovnyah sistemy, stremyashchejsya podavit'
vnesennoe izmenenie, a znachit sistema ploho prisposoblena k
izmeneniyam. Argument v pol'zu "nikakih izmenenij" ili "tol'ko lokal'nye
izmeneniya" chasto svoditsya k tomu, chto odin otdel ne hochet
perekladyvat' bol'shuyu rabotu na drugoj otdel "radi ih zhe blaga".
CHasto byvaet tak, chto ko vremeni, kogda oshibka uzhe najdena, ispisano
stol'ko bumagi otnositel'no oshibochnogo resheniya, chto usiliya,
nuzhnye na ispravlenie dokumentacii, zatmevayut usiliya dlya ispravleniya
samoj programmy. Takim obrazom, bumazhnaya rabota mozhet stat' glavnoj
problemoj processa sozdaniya sistemy. Konechno, takie problemy mogut byt'
i voznikayut v processe razvitiya bol'shih sistem. V konce koncov,
opredelennaya rabota s bumagami neobhodima. No vybor linejnoj modeli
razvitiya (kaskad) mnogokratno uvelichivaet veroyatnost', chto eta
problema vyjdet iz-pod kontrolya.
Nedostatok modeli kaskad v otsutstvii povtornyh prohodov i
nesposobnosti reagirovat' na izmeneniya. Opasnost' predlagaemoj zdes'
iterativnoj modeli sostoit v iskushenii zamenit' razmyshlenie i
real'noe razvitie na posledovatel'nost' beskonechnyh izmenenij.
Tot i drugoj nedostatki legche ukazat', chem ustranit', i dlya togo,
kto organizuet rabotu, legko prinyat' prostuyu aktivnost' za real'nyj
progress.
    Vy mozhete udelyat' pristal'noe vnimanie detalyam, ispol'zovat'
razumnye priemy upravleniya, razvituyu tehnologiyu, no nichto ne spaset
vas, esli net yasnogo ponimaniya togo, chto vy pytaetes' sozdat'. Bol'she
vsego proektov provalivalos' imenno iz-za otsutstviya horosho
sformulirovannyh realistichnyh celej, a ne po kakoj-libo inoj prichine.
CHto by vy ne delali i chem by ne zanimalis', nado yasno predstavlyat'
imeyushchiesya u vas sredstva, stavit' dostizhimye celi i orientiry i ne
iskat' tehnicheskih reshenij sociologicheskih problem. S drugoj storony,
nado primenyat' tol'ko adekvatnuyu tehnologiyu, dazhe esli ona potrebuet
zatrat,- lyudi rabotayut luchshe, imeya adekvatnye sredstva i priemlemuyu
sredu. Ne zabluzhdajtes', dumaya, chto legko vypolnit' eti rekomendacii.

        11.3.1 Cikl razvitiya

Process razvitiya sistemy - eto iterativnaya deyatel'nost'. Osnovnoj
cikl svoditsya k povtoryaemym v sleduyushchej posledovatel'nosti shagam:
 [1] Sozdat' obshchee opisanie proekta.
 [2] Vydelit' standartnye komponenty.
     [a] Podognat' komponenty pod dannyj proekt.
 [3] Sozdat' novye standartnye komponenty.
     [a] Podognat' komponenty pod dannyj proekt.
 [4] Sostavit' utochnennoe opisanie proekta.
V kachestve primera rassmotrim avtomobil'nyj zavod. Proekt dolzhen
nachinat'sya s samogo obshchego opisaniya novoj mashiny. |tot pervyj shag
baziruetsya na nekotorom analize i opisanii mashiny v samyh obshchih
terminah, kotorye skoree otnosyatsya k predpolagaemomu ispol'zovaniyu,
chem k harakteristikam zhelaemyh vozmozhnostej mashiny. CHasto samoj
trudnoj chast'yu proekta byvaet vybor zhelaemyh vozmozhnostej, ili,
tochnee, opredelenie otnositel'no prostogo kriteriya vybora zhelaemyh
vozmozhnostej. Udacha zdes', kak pravilo, yavlyaetsya
rezul'tatom raboty otdel'nogo pronicatel'nogo cheloveka i chasto
nazyvaetsya predvideniem. Slishkom tipichno kak raz otsutstvie
yasnyh celej, chto privodit k neuverenno razvivayushchimsya ili prosto
provalivayushchimsya proektam.
    Itak, dopustim neobhodimo sozdat' mashinu srednego razmera s
chetyr'mya dvercami i dostatochno moshchnym motorom. Ochevidno, chto
na pervom etape proekta ne sleduet nachinat' proektirovanie mashiny
(i vseh ee komponentov) s nulya. Hotya programmist ili razrabotchik
programmnogo obespecheniya v podobnyh obstoyatel'stvah postupit imenno
tak.
     Na pervom etape nado vyyasnit', kakie komponenty dostupny na
vashem sobstvennom sklade i kakie mozhno poluchit' ot nadezhnyh
postavshchikov. Najdennye takim obrazom komponenty ne obyazatel'no
v tochnosti podojdut dlya novoj mashiny. Vsegda trebuetsya podgonka
komponentov. Mozhet byt' dazhe potrebuetsya izmenit' harakteristiki
"sleduyushchej versii" vybrannyh komponentov, chtoby sdelat' ih
prigodnymi dlya proekta. Naprimer, mozhet sushchestvovat' vpolne prigodnyj
motor, vyrabatyvayushchij nemnogo men'shuyu moshchnost'.Togda
ili vy, ili postavshchik motora dolzhny predlozhit', ne izmenyaya obshchego
opisaniya proekta, v kachestve kompensacii dopolnitel'nyj
zaryadnyj generator.  Zametim, chto sdelat' eto,"ne izmenyaya obshchego opisaniya
proekta", maloveroyatno, esli tol'ko samo opisanie ne prisposobleno
k opredelennoj podgonke. Obychno podobnaya
podgonka trebuet kooperacii mezhdu vami i postavshchikom motorov.
Shodnye voprosy voznikayut i u programmista ili razrabotchika
programmnogo obespecheniya. Zdes' podgonku obychno oblegchaet effektivnoe
ispol'zovanie proizvodnyh klassov. No ne rasschityvajte provesti
proizvol'nye rasshireniya v proekte bez opredelennogo predvideniya
ili kooperacii s sozdatelem takih klassov.
    Kogda ischerpaetsya nabor podhodyashchih standartnyh komponentov,
proektirovshchik mashiny ne speshit zanyat'sya proektirovaniem novyh
optimal'nyh komponentov dlya svoej mashiny. |to bylo by slishkom
rastochitel'no. Dopustim, chto ne nashlos' podhodyashchego bloka
kondicionirovaniya vozduha, zato est' svobodnoe prostranstvo, imeyushchee
formu bukvy L, v motornom otseke. Vozmozhno reshenie razrabotat'
blok kondicionirovaniya ukazannoj formy. No veroyatnost' togo, chto
blok podobnoj strannoj formy budet ispol'zovat'sya v mashinah drugogo
tipa (dazhe posle znachitel'noj podgonki), krajne nizka. |to oznachaet,
chto nash proektirovshchik mashiny ne smozhet razdelit' zatraty na
proizvodstvo takogo bloka s sozdatelyami mashin drugogo tipa, a znachit
vremya zhizni etogo bloka korotko. Poetomu stoit sproektirovat' blok,
kotoryj najdet bolee shirokoe primenenie, t.e. razrabotat'
razumnyj proekt bloka, bolee prisposoblennyj dlya podgonki, chem nashe
L-obraznoe chudishche. Vozmozhno, eto potrebuet bol'shih usilij, i dazhe
pridetsya dlya prisposobleniya bolee universal'nogo bloka izmenit'
obshchee opisanie proekta mashiny. Poskol'ku novyj blok razrabatyvalsya
dlya bolee obshchego primeneniya, chem nashe L-obraznoe chudishche,
predpolozhitel'no, dlya nego potrebuetsya nekotoraya podgonka, chtoby
polnost'yu udovletvorit' nashi peresmotrennye zaprosy.
Podobnaya zhe al'ternativa voznikaet i u programmista ili razrabotchika
programmnogo obespecheniya: vmesto togo, chtoby sozdat' programmu,
privyazannuyu k konkretnomu proektu, razrabotchik mozhet sproektirovat'
novuyu dostatochno universal'nuyu programmu, kotoraya budet imet'
horoshie shansy stat' standartnoj v opredelennoj oblasti.
     Nakonec, kogda my proshlis' po vsem standartnym komponentam,
sostavlyaetsya "okonchatel'noe" obshchee opisanie proekta. Neskol'ko
special'no razrabotannyh sredstv ukazyvayutsya kak vozmozhnye. Veroyatno,
v sleduyushchem godu pridetsya dlya novoj modeli povtorit' nashi shagi,
i kak raz eti special'nye sredstva pridetsya peredelat' ili vybrosit'.
Kak ni pechal'no, no opyt tradicionno proektirovavshihsya programm
pokazyvaet, chto lish' neskol'ko chastej sistemy mozhno vydelit' v
otdel'nye komponenty i lish' neskol'ko iz nih prigodny vne
dannogo proekta.
     My ne pytaemsya utverzhdat', chto vse razrabotchiki mashin
dejstvuyut stol' razumno, kak v privedennom primere, a razrabotchiki
programm sovershayut vse ukazannye oshibki. Utverzhdaetsya, chto ukazannaya
metodika razrabotki mashin primenima i dlya programmnogo obespecheniya.
Tak, v etoj i sleduyushchej glavah dany priemy ispol'zovaniya ee dlya S++.
Tem ne menee mozhno skazat', chto sama priroda programmirovaniya
sposobstvuet soversheniyu ukazannyh oshibok ($$12.2.1 i $$12.2.5).
V razdele 11.4.3 oprovergaetsya professional'noe predubezhdenie protiv
ispol'zovaniya opisannoj zdes' modeli proektirovaniya.
 Zametim, chto model' razvitiya programmnogo obespecheniya horosho
primenima tol'ko v raschete na bol'shie sroki. Esli vash gorizont
suzhaetsya do vremeni vydachi ocherednoj versii, net smysla sozdavat'
i podderzhivat' funkcionirovanie standartnyh komponentov. |to
prosto privedet k izlishnim nakladnym rashodam. Nasha model'
rasschitana na organizacii so vremenem zhizni, za kotoroe prohodit
neskol'ko proektov, i s razmerami, kotorye pozvolyayut nesti
dopolnitel'nye rashody i na sredstva proektirovaniya, programmirovaniya,
i na soprovozhdenie proektov, i na povyshenie kvalifikacii razrabotchikov,
programmistov i menedzherov. Fakticheski eto eskiz nekotoroj fabriki po
proizvodstvu programm. Kak ni udivitel'no, ona tol'ko masshtabom
otlichaetsya ot dejstvij luchshih programmistov, kotorye dlya povysheniya svoej
proizvoditel'nosti v techenii let nakaplivali zapas priemov i metodov
proektirovaniya, sozdavali instrumenty i biblioteki. Pohozhe, chto
bol'shinstvo organizacij prosto ne umeet vospol'zovat'sya dostizheniyami
luchshih sotrudnikov, kak iz-za otsutstviya predvideniya, tak i po
nesposobnosti primenit' eti dostizheniya v dostatochno shirokom
ob容me.
    Vse-taki nerazumno trebovat', chtoby "standartnye komponenty"
byli standartnymi universal'no. Sushchestvuet lish' maloe chislo
mezhdunarodnyh standartnyh bibliotek, a v svoem bol'shinstve komponenty
okazhutsya standartnymi tol'ko v predelah strany, otrasli, kompanii,
proizvodstvennoj cepochki, otdela ili oblasti prilozheniya i t.d.
Prosto mir slishkom velik, chtoby universal'nyj standart
vseh komponentov i sredstv byl real'noj ili zhelannoj cel'yu proekta.


        11.3.2 Celi proektirovaniya

Kakovy samye obshchie celi proektirovaniya? Konechno, prostota, no v chem
kriterij prostoty? Poskol'ku my schitaem, chto proekt dolzhen razvivat'sya
vo vremeni, t.e. sistema budet rasshiryat'sya, perenosit'sya,
nastraivat'sya i, voobshche, izmenyat'sya massoj sposobov, kotorye nevozmozhno
predusmotret', neobhodimo stremit'sya k takoj sisteme proektirovaniya
i realizacii, kotoraya byla by prostoj s uchetom, chto ona budet
menyat'sya mnogimi sposobami. Na samom dele, praktichno dopustit',
chto sami trebovaniya k sisteme budut menyat'sya neodnokratno za period
ot nachal'nogo proekta do vydachi pervoj versii sistemy.
     Vyvod takov: sistema dolzhna proektirovat'sya maksimal'no prostoj
pri uslovii, chto ona budet podvergat'sya serii izmenenij. My dolzhny
proektirovat' v raschete na izmeneniya, t.e. stremit'sya k
  - gibkosti,
  - rasshiryaemosti i
  - perenosimosti
Luchshee reshenie - vydelit' chasti sistemy, kotorye veroyatnee vsego budut
menyat'sya, v samostoyatel'nye edinicy, i predostavit' programmistu ili
razrabotchiku gibkie vozmozhnosti dlya modifikacij takih edinic. |to
mozhno sdelat', esli vydelit' klyuchevye dlya dannoj zadachi ponyatiya
i predostavit' klass, otvechayushchij za vsyu informaciyu, svyazannuyu s
otdel'nym ponyatiem (i tol'ko s nim). Togda izmenenie budet zatragivat'
tol'ko opredelennyj klass. Estestvenno, takoj ideal'nyj sposob
gorazdo legche opisat', chem voplotit'.
   Rassmotrim primer: v zadache modelirovaniya meteorologicheskih
ob容ktov nuzhno predstavit' dozhdevoe oblako. Kak eto sdelat'?
U nas net obshchego metoda izobrazheniya oblaka, poskol'ku ego vid zavisit
ot vnutrennego sostoyaniya oblaka, a ono mozhet byt' zadano tol'ko
samim oblakom.
    Pervoe reshenie: pust' oblako izobrazhaet sebya samo. Ono podhodit
dlya mnogih ogranichennyh prilozhenij. No ono ne yavlyaetsya dostatochno
obshchim, poskol'ku sushchestvuet mnogo sposobov predstavleniya oblaka:
detal'naya kartina, nabrosok ochertanij, piktogramma, karta i t.p.
Drugimi slovami, vid oblaka opredelyaetsya kak im samim, tak i ego
okruzheniem.
    Vtoroe reshenie zaklyuchaetsya v tom, chtoby predostavit' samomu oblaku
dlya ego izobrazheniya svedeniya o ego okruzhenii. Ono goditsya dlya
bol'shego chisla sluchaev. Odnako i eto ne obshchee reshenie. Esli my
predostavlyaem oblaku svedeniya ob ego okruzhenii, to narushaem osnovnoj
postulat, kotoryj trebuet, chtoby klass otvechal tol'ko za odno
ponyatie, i kazhdoe ponyatie voploshchalos' opredelennym klassom.
Mozhet okazat'sya nevozmozhnym predlozhit' soglasovannoe opredelenie
"okruzheniya oblaka", poskol'ku, voobshche govorya, kak vyglyadit oblako
zavisit ot samogo oblaka i nablyudatelya. CHem predstavlyaetsya oblako
mne, sil'no zavisit ot togo, kak ya smotryu na nego: nevooruzhennym
glazom, s pomoshch'yu polyarizacionnogo fil'tra, s pomoshch'yu meteoradara i t.d.
Pomimo nablyudatelya i oblaka sleduet uchityvat' i "obshchij fon", naprimer,
otnositel'noe polozhenie solnca. K dal'nejshemu uslozhneniyu kartiny
privodit dobavlenie novyh ob容ktov tipa drugih oblakov, samoletov.
CHtoby sdelat' zadachu razrabotchika prakticheski nerazreshimoj, mozhno
dobavit' vozmozhnost' odnovremennogo sushchestvovaniya neskol'kih
nablyudatelej.
     Tret'e reshenie sostoit v tom, chtoby oblako, a takzhe i drugie
ob容kty, naprimer, samolety ili solnce, sami opisyvali sebya po
otnosheniyu k nablyudatelyu. Takoj podhod obladaet dostatochnoj
obshchnost'yu, chtoby udovletvorit' bol'shinstvo zaprosovX. Odnako,
on mozhet privesti k znachitel'nomu uslozhneniyu i bol'shim nakladnym
rashodam pri vypolnenii. Kak, naprimer, dobit'sya togo, chtoby
nablyudatel' ponimal opisaniya, proizvedennye oblakom ili drugimi
ob容ktami?

X Dazhe eta model' budet, po vsej vidimosti, ne dostatochnoj dlya takih
  predel'nyh sluchaev, kak grafika s vysokoj stepen'yu razreshimosti.
  YA dumayu, chto dlya polucheniya ochen' detal'noj kartiny nuzhen drugoj
  uroven' abstrakcii.

     Dozhdevye oblaka - eto ne tot ob容kt, kotoryj chasto vstretish'
v programmah, no ob容kty, uchastvuyushchie v razlichnyh operaciyah vvoda
i vyvoda, vstrechayutsya chasto. Poetomu mozhno schitat' primer s oblakom
prigodnym dlya programmirovaniya voobshche i dlya razrabotki bibliotek
v chastnosti. Logicheski shozhij primer v S++ predstavlyayut manipulyatory,
kotorye ispol'zuyutsya dlya formatirovaniya vyvoda v potokovom
vvode-vyvode ($$10.4.2). Zametim, chto tret'e reshenie ne est' "vernoe
reshenie", eto prosto bolee obshchee reshenie. Razrabotchik dolzhen
sbalansirovat' razlichnye trebovaniya sistemy, chtoby najti uroven'
obshchnosti i abstrakcii, prigodnyj dlya dannoj zadachi v dannoj oblasti.
Zolotoe pravilo: dlya programmy s dolgim srokom zhizni pravil'nym
budet samyj obshchij uroven' abstrakcii, kotoryj vam eshche ponyaten i
kotoryj vy mozhete sebe pozvolit', no ne obyazatel'no absolyutno
obshchij. Obobshchenie, vyhodyashchee za predely dannogo proekta i
ponyatiya lyudej, v nem uchastvuyushchih, mozhet prinesti vred, t.e.
privesti k zaderzhkam, nepriemlemym harakteristikam, neupravlyaemym
proektam i prosto k provalu.
     CHtoby ispol'zovanie ukazannyh metodov bylo ekonomichno i
poddavalos' upravleniyu, proektirovanie i upravlenie dolzhno
uchityvat' povtornoe ispol'zovanie, o chem govoritsya v $$11.4.1 i
ne sleduet sovsem zabyvat' ob effektivnosti (sm. $$11.3.7).

        11.3.3 SHagi proektirovaniya

Rassmotrim proektirovanie otdel'nogo klassa. Obychno eto ne luchshij
metod. Ponyatiya ne sushchestvuyut izolirovanno, naoborot, ponyatie
opredelyaetsya v svyazi s drugimi ponyatiyami. Analogichno i klass ne
sushchestvuet izolirovanno, a opredelyaetsya sovmestno s mnozhestvom
svyazannyh mezhdu soboj klassov. |to mnozhestvo chasto nazyvayut
bibliotekoj klassov ili komponentom. Inogda vse klassy komponenta
obrazuyut edinuyu ierarhiyu, inogda eto ne tak (sm. $$12.3).
   Mnozhestvo klassov komponenta byvayut ob容dineny nekotorym logicheskim
usloviem, inogda eto - obshchij stil' programmirovaniya ili opisaniya,
inogda - predostavlyaemyj servis. Komponent yavlyaetsya edinicej
proektirovaniya, dokumentacii, prava sobstvennosti i,
chasto, povtornogo ispol'zovaniya.
|to ne oznachaet, chto esli vy ispol'zuete odin klass komponenta, to
dolzhny razbirat'sya vo vseh i umet' primenyat' vse klassy komponenta ili
dolzhny podgruzhat' k vashej programme moduli vseh klassov komponenta. V
tochnosti naoborot, obychno stremyatsya obespechit', chtoby ispol'zovanie
klassa velo k minimumu nakladnyh rashodov: kak mashinnyh resursov,
tak i chelovecheskih usilij. No dlya ispol'zovaniya lyubogo klassa
komponenta nuzhno ponimat' logicheskoe uslovie, kotoroe ego
opredelyaet (mozhno nadeyat'sya, chto ono predel'no yasno izlozheno v
dokumentacii), ponimat' soglasheniya i stil', primenennyj v processe
proektirovaniya i opisaniya komponenta, i dostupnyj servis (esli on
est').
     Itak, perejdem k sposobam proektirovaniya komponenta. Poskol'ku
chasto eto neprostaya zadacha, imeet smysl razbit' ee na shagi i,
skoncentrirovavshis' na podzadachah, dat' polnoe i posledovatel'noe
opisanie. Obychno net edinstvenno pravil'nogo sposoba razbieniya.
Tem ne menee, nizhe privoditsya opisanie posledovatel'nosti shagov,
kotoraya prigodilas' v neskol'kih sluchayah:
  [1] Opredelit' ponyatie / klass i ustanovit' osnovnye svyazi
      mezhdu nimi.
  [2] Utochnit' opredeleniya klassov, ukazav nabor operacij dlya
      kazhdogo.
      [a] Provesti klassifikaciyu operacij. V chastnosti utochnit'
          neobhodimost' postroeniya, kopirovaniya i unichtozheniya.
      [b] Ubedit'sya v minimal'nosti, polnote i udobstve.
  [3] Utochnit' opredeleniya klassov, ukazav ih zavisimost' ot
      drugih klassov.
      [a] Nasledovanie.
      [b] Ispol'zovanie zavisimostej.
  [4] Opredelit' interfejsy klassov.
      [a] Podelit' funkcii na obshchie i zashchishchennye.
      [b] Opredelit' tochnyj tip operacij klassa.
Otmetim, chto eto shagi iterativnogo processa. Obychno dlya polucheniya
proekta, kotoryj mozhno uverenno ispol'zovat' dlya pervichnoj realizacii
ili povtornoj realizacii, nuzhno neskol'ko raz prodelat'
posledovatel'nost' shagov. Odnim iz preimushchestv glubokogo analiza i
predlozhennoj zdes'  abstrakcii  dannyh  okazyvaetsya otnositel'naya
legkost', s kotoroj mozhno perestroit' vzaimootnosheniya klassov
dazhe posle programmirovaniya kazhdogo klassa. Hotya eto nikogda ne
byvaet prosto.
     Dalee sleduet pristupit' k realizacii klassov, a zatem
vernut'sya, chtoby ocenit' proekt, ishodya iz opyta realizacii.
Rassmotrim eti shagi v otdel'nosti.

        11.3.3.1 SHag 1: opredelenie klassov

Opredelite ponyatiya/klassy i ustanovite osnovnye svyazi mezhdu nimi.
Glavnoe v horoshem proekte - pryamo otrazit' kakoe-libo ponyatie
"real'nosti", t.e. ulovit' ponyatie iz oblasti prilozheniya klassov,
predstavit' vzaimosvyaz' mezhdu klassami strogo opredelennym sposobom,
naprimer, s pomoshch'yu nasledovaniya, i povtorit' eti dejstviya na
raznyh urovnyah abstrakcii. No kak my mozhem ulovit' eti ponyatiya?
Kak na praktike reshit', kakie nam nuzhny klassy?
     Luchshe poiskat' otvet v samoj oblasti prilozheniya, chem ryt'sya
v programmistskom hranilishche abstrakcij i ponyatij. Obratites' k tomu,
kto stal ekspertom po rabote v nekogda sdelannoj sisteme, a takzhe
k tomu, kto stal kritikom sistemy, prishedshej ej na smenu. Zapomnite
vyrazheniya togo i drugogo.
    CHasto govoryat, chto sushchestvitel'nye igrayut rol' klassov i ob容ktov,
ispol'zuemyh v programme, eto dejstvitel'no tak. No eto tol'ko nachalo.
Dalee, glagoly mogut predstavlyat' operacii nad ob容ktami ili
obychnye (global'nye) funkcii, vyrabatyvayushchie novye znacheniya, ishodya
iz svoih parametrov, ili dazhe klassy. V kachestve primera
mozhno rassmatrivat' funkcional'nye ob容kty, opisannye v $$10.4.2.
Takie glagoly, kak "povtorit'" ili "sovershit'" (commit) mogut byt'
predstavleny iterativnym ob容ktom ili ob容ktom, predstavlyayushchim
operaciyu vypolneniya programmy v bazah dannyh.
Dazhe prilagatel'nye mozhno uspeshno
predstavlyat' s pomoshch'yu klassov, naprimer, takie, kak "hranimyj",
"parallel'nyj", "registrovyj", "ogranichennyj". |to mogut byt' klassy,
kotorye pomogut razrabotchiku ili programmistu, zadav virtual'nye
bazovye klassy, specificirovat' i vybrat' nuzhnye svojstva dlya
klassov, proektiruemyh pozdnee.
     Luchshee sredstvo dlya poiska etih ponyatij / klassov - grifel'naya
doska, a luchshij metod pervogo utochneniya - eto beseda so specialistami
v oblasti prilozheniya ili prosto s druz'yami. Obsuzhdenie neobhodimo,
chtoby sozdat' nachal'nyj zhiznesposobnyj slovar' terminov i ponyatijnuyu
strukturu. Malo kto mozhet sdelat' eto v odinochku. Obratites' k [1],
chtoby uznat' o metodah podobnyh utochnenij.
     Ne vse klassy sootvetstvuyut ponyatiyam iz oblasti prilozheniya.
Nekotorye mogut predstavlyat' resursy sistemy ili abstrakcii
perioda realizacii (sm. $$12.2.1).
     Vzaimootnosheniya, o kotoryh my govorim, estestvenno ustanavlivayutsya
v oblasti prilozheniya ili (v sluchae povtornyh prohodov po shagam
proektirovaniya) voznikayut iz posleduyushchej raboty nad strukturoj klassov.
Oni otrazhayut nashe ponimanie osnov oblasti prilozheniya. CHasto oni
yavlyayutsya klassifikaciej osnovnyh ponyatij. Primer takogo otnosheniya:
mashina s vydvizhnoj lestnicej est' gruzovik, est' pozharnaya mashina,
est' dvizhushcheesya sredstvo.
V $$11.3.3.2 i $$11.3.3.5 predlagaetsya nekotoraya tochka zreniya na
klassy i ierarhiyu klassov, esli neobhodimo uluchshit' ih strukturu.

        11.3.3.2 SHag 2: opredelenie nabora operacij

Utochnite opredeleniya klassov, ukazav nabor operacij dlya kazhdogo.
V dejstvitel'nosti nel'zya razdelit' processy opredeleniya klassov i
vyyasneniya togo, kakie operacii dlya nih nuzhny. Odnako, na praktike
oni razlichayutsya, poskol'ku pri opredelenii klassov vnimanie
koncentriruetsya na osnovnyh ponyatiyah, ne ostanavlivayas'
na programmistskih voprosah ih realizacii, togda kak pri opredelenii
operacij prezhde vsego sosredotachivaetsya na tom, chtoby zadat' polnyj i
udobnyj nabor operacij. CHasto byvaet slishkom trudno sovmestit' oba
podhoda, v osobennosti, uchityvaya, chto svyazannye klassy nado
proektirovat' odnovremenno.
   Vozmozhno neskol'ko podhodov k processu opredeleniya nabora operacij.
Predlagaem sleduyushchuyu strategiyu:
   [1] Rassmotrite, kakim obrazom ob容kt klassa budet sozdavat'sya,
       kopirovat'sya (esli nuzhno) i unichtozhat'sya.
   [2] Opredelite minimal'nyj nabor operacij, kotoryj neobhodim
       dlya ponyatiya, predstavlennogo klassom.
   [3] Rassmotrite operacii, kotorye mogut byt' dobavleny dlya udobstva
       zapisi, i vklyuchite tol'ko neskol'ko dejstvitel'no vazhnyh.
   [4] Rassmotrite, kakie operacii mozhno schitat' trivial'nymi, t.e.
       takimi, dlya kotoryh klass vystupaet v roli interfejsa dlya
       realizacii proizvodnogo klassa.
   [5] Rassmotrite, kakoj obshchnosti imenovaniya i funkcional'nosti
       mozhno dostignut' dlya vseh klassov komponenta.
Ochevidno, chto eto - strategiya minimalizma. Gorazdo proshche dobavlyat'
lyubuyu funkciyu, prinosyashchuyu oshchutimuyu pol'zu, i sdelat' vse operacii
virtual'nymi. No, chem bol'she funkcij, tem bol'she veroyatnost', chto
oni ne budut ispol'zovat'sya, nalozhat opredelennye ogranicheniya na
realizaciyu i zatrudnyat evolyuciyu sistemy. Tak, funkcii, kotorye
mogut neposredstvenno chitat' i pisat' v peremennuyu sostoyaniya ob容kta
iz klassa, vynuzhdayut ispol'zovat' edinstvennyj sposob realizacii i
znachitel'no sokrashchayut vozmozhnosti pereproektirovaniya. Takie funkcii
snizhayut uroven' abstrakcii ot ponyatiya do ego konkretnoj realizacii.
K tomu zhe dobavlenie funkcij dobavlyaet raboty programmistu i
dazhe razrabotchiku, kogda on vernetsya k proektirovaniyu. Gorazdo
legche vklyuchit' v interfejs eshche odnu funkciyu, kak tol'ko
ustanovlena potrebnost' v nej, chem udalit' ee ottuda, kogda uzhe
ona stala privychnoj.
      Prichina, po kotoroj my trebuem yavnogo prinyatiya resheniya o
virtual'nosti dannoj funkcii, ne ostavlyaya ego na stadiyu realizacii,
v tom, chto, ob座aviv funkciyu virtual'noj, my sushchestvenno povliyaem
na ispol'zovanie ee klassa i na vzaimootnosheniya etogo klassa s
drugimi. Ob容kty iz klassa, imeyushchego hotya by odnu virtual'nuyu
funkciyu, trebuyut netrivial'nogo raspredeleniya pamyati, esli sravnit'
ih s ob容ktami iz takih yazykov kak S ili Fortran. Klass s hotya by
odnoj virtual'noj funkciej po suti vystupaet v roli interfejsa
po otnosheniyu k klassam, kotorye "eshche mogut byt' opredeleny", a
virtual'naya funkciya predpolagaet zavisimost' ot klassov, kotorye
"eshche mogu byt' opredeleny" (sm. $$12.2.3)
     Otmetim, chto strategiya minimalizma trebuet, pozhaluj, bol'shih
usilij so storony razrabotchika.
     Pri opredelenii nabora operacij bol'she vnimaniya sleduet udelyat'
tomu, chto nado sdelat', a ne tomu, kak eto delat'.
     Inogda polezno klassificirovat' operacii klassa po tomu,
kak oni rabotayut s vnutrennim sostoyaniem ob容ktov:
  - Bazovye operacii: konstruktory, destruktory, operacii kopirovaniya.
  - Selektory: operacii, ne izmenyayushchie sostoyaniya ob容kta.
  - Modifikatory: operacii, izmenyayushchie sostoyanie ob容kta.
  - Operacii preobrazovanij, t.e. operacii porozhdayushchie ob容kt
    drugogo tipa, ishodya iz znacheniya (sostoyaniya) ob容kta, k kotoromu
    oni primenyayutsya.
  - Povtoriteli: operacii, kotorye otkryvayut dostup k ob容ktam klassa
    ili ispol'zuyut posledovatel'nost' ob容ktov.
|to ne est' razbienie na ortogonal'nye gruppy operacij. Naprimer,
povtoritel' mozhet byt' sproektirovan kak selektor ili modifikator.
Vydelenie etih grupp prosto prednaznacheno pomoch' v processe
proektirovaniya interfejsa klassa. Konechno, dopustima i drugaya
klassifikaciya. Provedenie takoj klassifikacii osobenno polezno dlya
podderzhaniya neprotivorechivosti mezhdu klassami v ramkah odnogo
komponenta.
    V yazyke S++ est' konstrukciya, pomogayushchaya zadaniyu selektorov i
modifikatorov v vide funkcii-chlena so specifikaciej const i bez nee.
Krome togo, est' sredstva, pozvolyayushchie yavno zadat' konstruktory,
destruktory i funkcii preobrazovaniya. Operaciya kopirovaniya realizuetsya
s pomoshch'yu operacij prisvaivaniya i konstruktorov kopirovaniya.

        11.3.3.3 SHag 3: ukazanie zavisimostej

Utochnite opredelenie klassov, ukazav ih zavisimosti ot drugih klassov.
Razlichnye vidy zavisimostej obsuzhdayutsya v $$12.2. Osnovnymi po
otnosheniyu k proektirovaniyu sleduet schitat' otnosheniya nasledovaniya
i ispol'zovaniya. Oba predpolagayut ponimanie togo, chto znachit dlya
klassa otvechat' za opredelennoe svojstvo sistemy. Otvechat' za chto-libo
ne oznachaet, chto klass dolzhen soderzhat' v sebe vsyu informaciyu, ili,
chto ego funkcii-chleny dolzhny sami provodit' vse neobhodimye operacii.
Kak raz naoborot, kazhdyj klass, imeyushchij opredelennyj uroven'
otvetstvennosti, organizuet rabotu, pereporuchaya ee v vide
podzadach drugim klassam, kotorye imeyut men'shij uroven' otvetstvennosti.
No nado predosterech', chto zloupotreblenie etim priemom privodit
k neeffektivnym i ploho ponimaemym proektam, poskol'ku
proishodit razmnozhenie klassov i ob容ktov do takoj stepeni, chto
vmesto real'noj raboty proizvoditsya tol'ko seriya zaprosov na
ee vypolnenie. To, chto mozhno sdelat' v dannom meste, sleduet
sdelat'.
     Neobhodimost' uchest' otnosheniya nasledovaniya i ispol'zovaniya
na etape proektirovaniya (a ne tol'ko v processe realizacii) pryamo
vytekaet iz togo, chto klassy predstavlyayut opredelennye ponyatiya.
Otsyuda takzhe sleduet, chto imenno komponent (t.e. mnozhestvo
svyazannyh klassov), a ne otdel'nyj klass, yavlyayutsya edinicej
proektirovaniya.

        11.3.3.4 SHag 4: opredelenie interfejsov

Opredelite interfejsy klassov. Na etoj stadii proektirovaniya ne nuzhno
rassmatrivat' privatnye funkcii. Voprosy realizacii, voznikayushchie na
stadii proektirovaniya, luchshe vsego obsuzhdat' na shage 3 pri
rassmotrenii razlichnyh zavisimostej. Bolee togo, sushchestvuet
zolotoe pravilo: esli klass ne dopuskaet po krajnej mere dvuh
sushchestvenno otlichayushchihsya realizacij, to chto-to yavno ne v poryadke s etim
klassom, eto prosto zamaskirovannaya realizaciya, a ne predstavlenie
abstraktnogo ponyatiya. Vo mnogih sluchayah dlya otveta na vopros:
"Dostatochno li interfejs klassa nezavisim ot realizacii?"- nado
ukazat', vozmozhna li dlya klassa shema lenivyh vychislenij.
   Otmetim, chto obshchie bazovye klassy i druz'ya (friend) yavlyayutsya
chast'yu obshchego interfejsa klassa (sm. $$5.4.1 i $$12.4). Poleznym
uprazhneniem mozhet byt' opredelenie razdel'nogo interfejsa dlya
klassov-naslednikov i vseh ostal'nyh klassov s pomoshch'yu razbieniya
interfejsa na obshchuyu i zakrytye chasti.
   Imenno na etom shage sleduet produmat' i opisat' tochnye opredeleniya
tipov argumentov. V ideale zhelatel'no imet' maksimal'noe chislo
interfejsov so staticheskimi tipami, otnosyashchimisya k oblasti prilozheniya
(sm. $$12.1.3 i $$12.4).
    Pri opredelenii interfejsov sleduet obratit' vnimanie na te
klassy, gde nabor operacij predstavlen bolee, chem na odnom urovne
abstrakcii. Naprimer, v klasse file u nekotoryh funkcij-chlenov
argumenty imeyut tip file_descriptor (deskriptor_fajla), a u drugih
argumenty - stroka simvolov, kotoraya oboznachaet imya fajla.
Operacii s file_descriptor rabotayut na drugom urovne (men'shem)
abstrakcii, chem operacii s imenem fajla, tak chto dazhe stranno,
chto oni otnosyatsya k odnomu klassu. Vozmozhno, bylo by luchshe imet'
dva klassa: odin predstavlyaet ponyatie deskriptora fajla, a
drugoj - ponyatie imeni fajla. Obychno vse operacii klassa dolzhny
predstavlyat' ponyatiya odnogo urovnya abstrakcii. Esli eto ne tak,
to stoit podumat' o reorganizacii i ego, i svyazannyh s nim klassov.

        11.3.3.5 Perestrojka ierarhii klassov

 SHagi 1 i 3 trebuyut issledovaniya klassov i ih ierarhii, chtoby
ubedit'sya, chto oni adekvatno otvechayut nashim trebovaniyam. Obychno
eto ne tak, i prihoditsya provodit' perestrojku dlya uluchsheniya
struktury, proekta ili realizacii.
     Samaya tipichnaya perestrojka ierarhii klassov sostoit v vydelenii
obshchej chasti dvuh klassov v novyj klass ili v razbienii klassa na dva
novyh. V oboih sluchayah v rezul'tate poluchitsya tri klassa:
bazovyj klass i dva
proizvodnyh. Kogda sleduet provodit' takuyu perestrojku? Kakovy
obshchie pokazaniya, chto takaya perestrojka budet poleznoj?
     K sozhaleniyu net prostogo i universal'nogo otveta na eti
voprosy. |to i ne udivitel'no, poskol'ku to, chto predlagaetsya,
ne yavlyaetsya meloch'yu pri realizacii, a izmenyaet osnovnye
ponyatiya sistemy. Vazhnoj i netrivial'noj zadachej yavlyaetsya poisk
obshchnosti sredi klassov i vydelenie obshchej chasti.  Net tochnogo
opredeleniya obshchnosti, no sleduet obrashchat' vnimanie na obshchnost'
dlya ponyatij sistemy, a ne prosto dlya udobstva realizacii. Ukazaniyami,
chto dva klassa imeyut nechto obshchee, chto vozmozhno vydelit' v obshchij bazovyj
klass, sluzhat shozhie sposoby ispol'zovaniya, shodstvo naborov operacij,
shodstvo realizacij i prosto tot fakt, chto chasto v processe obsuzhdeniya
proekta oba   klassa   poyavlyayutsya  odnovremenno.  S drugoj
storony,  esli  est'
neskol'ko naborov operacij klassa s razlichnymi sposobami ispol'zovaniya,
esli eti nabory obespechivayut dostup k razdel'nym podmnozhestvam ob容ktov
realizacii, i, esli klass voznikaet v processe obsuzhdeniya nesvyazannyh
tem, to etot klass yavlyaetsya yavnym kandidatom dlya razbieniya na chasti.
       V silu tesnoj svyazi mezhdu ponyatiyami i klassami problemy
perestrojki ierarhii klassov vysvechivayutsya na poverhnosti problem
imenovaniya klassov i ispol'zovaniya imen klassov v processe obsuzhdeniya
proekta. Esli imena klassov i ih uporyadochennost', zadavaemaya ierarhiej
klassov, kazhutsya neudobnymi pri obsuzhdenii proekta, znachit, po vsej
vidimosti, est' vozmozhnost' uluchsheniya ierarhii. Zametim, chto
podrazumevaetsya, chto analiz ierarhii klassov luchshe provodit' ne v
odinochku. Esli vy okazalis' v takom polozhenii, kogda ne s kem
obsudit' proekt, horoshim vyhodom budet popytat'sya sostavit' uchebnoe
opisanie sistemy, ispol'zuya imena klassov.

        11.3.3.6 Ispol'zovanie modelej

Kogda pishesh' stat'yu, pytaesh'sya najti podhodyashchuyu dlya temy model'. Nuzhno
ne brosat'sya srazu pechatat' tekst, a poiskat' stat'i na shodnye temy,
vdrug najdetsya takaya, kotoraya mozhet posluzhit' otpravnoj tochkoj.
Esli eyu okazhetsya moya sobstvennaya stat'ya, to mozhno budet ispol'zovat'
dazhe kuski iz nee, izmenyaya po mere nadobnosti drugie chasti, i vvodit'
novuyu informaciyu tol'ko tam, gde trebuet logika predmeta. Takim
obrazom, ishodya iz pervogo izdaniya, napisana eta kniga. Predel'nyj
sluchaj takogo podhoda - eto napisanie otkrytki-formulyara, gde prosto
nuzhno ukazat' imya i, vozmozhno, dobavit' paru strok dlya pridaniya
"lichnogo" otnosheniya. Po suti takie otkrytki pishutsya s ukazaniem otlichiya
ot standarta.
     Vo vseh vidah tvorcheskoj deyatel'nosti ispol'zovanie sushchestvuyushchih
sistem v kachestve modelej dlya novyh proektov yavlyaetsya skoree pravilom,
a ne isklyucheniem. Vsegda, kogda eto vozmozhno, proektirovanie i
programmirovanie dolzhny osnovyvat'sya na predydushchih rabotah. |to
sokrashchaet stepeni svobody dlya razrabotchika i pozvolyaet sosredotochit'
vnimanie na men'shem chisle voprosov v zadannoe vremya. Nachat' bol'shoj
proekt "prakticheski s nulya" - eto mozhet vozbuzhdat', no pravil'nee budet
upotrebit' termin "op'yanenie", kotoroe privedet k "p'yanomu
bluzhdaniyu" v mnozhestve variantov. Postroenie modeli ne nakladyvaet
kakih-libo ogranichenij i ne oznachaet pokornogo sledovaniya ej, eto
prosto osvobozhdaet razrabotchika ot nekotoryh voprosov.
     Zametim, chto na samom dele ispol'zovanie modelej neizbezhno,
poskol'ku kazhdyj proekt sinteziruetsya iz opyta ego razrabotchikov.
Luchshe, kogda ispol'zovanie modeli yavlyaetsya yavno sformulirovannym
resheniem, togda vse dopushcheniya delayutsya yavno, opredelyaetsya obshchij
slovar' terminov, poyavlyaetsya nachal'nyj karkas proekta i uvelichivaetsya
veroyatnost' togo, chto u razrabotchikov est' obshchij podhod.
      Estestvenno, chto vybor nachal'noj modeli yavlyaetsya vazhnym resheniem,
i obychno ono prinimaetsya tol'ko posle poiska potencial'nyh modelej
i tshchatel'noj ocenki variantov. Bolee togo, vo mnogih sluchayah model'
podhodit tol'ko pri uslovii ponimaniya togo, chto potrebuyutsya
znachitel'nye izmeneniya dlya voploshcheniya ee idej v inoj oblasti
prilozheniya. No proektirovanie programmnogo obespecheniya - tyazhelyj
trud, i nado ispol'zovat' lyubuyu pomoshch'. Ne sleduet otkazyvat'sya
ot ispol'zovaniya modelej iz-za neopravdannogo prenebrezheniya k
imitacii. Imitaciya - ne chto inoe, kak forma iskrennego voshishcheniya,
a, s uchetom prava sobstvennosti i avtorskogo prava, ispol'zovanie
modelej i predshestvuyushchih rabot v kachestve istochnika vdohnoveniya -
dopustimyj sposob dlya vseh novatorskih rabot vo vseh vidah
deyatel'nosti. To, chto bylo pozvoleno SHekspiru, podhodit i dlya nas.
Nekotorye oboznachayut ispol'zovanie modelej v processe proektirovaniya
kak "proektirovanie povtornogo ispol'zovaniya".

        11.3.4 |ksperiment i analiz

V nachale chestolyubivogo proekta nam neizvesten luchshij sposob postroeniya
sistemy. CHasto byvaet tak, chto my dazhe ne znaem tochno, chto dolzhna
delat' sistema, poskol'ku konkretnye fakty proyasnyatsya tol'ko v processe
postroeniya, testirovaniya i ekspluatacii sistemy. Kak zadolgo do
sozdaniya zakonchennoj sistemy poluchit' svedeniya, neobhodimye dlya
ponimaniya togo, kakie resheniya pri proektirovanii okazhutsya
sushchestvennymi, i k kakim posledstviyam oni privedut?
     Nuzhno provodit' eksperimenty. Konechno, nuzhen analiz proekta i ego
realizacii, kak tol'ko poyavlyaetsya pishcha dlya nego. Preimushchestvenno
obsuzhdenie vertitsya vokrug al'ternativ pri proektirovanii i
realizacii. Za isklyucheniem redkih sluchaev proektirovanie est'
social'naya aktivnost', kotoraya vedet po puti prezentacii i
obsuzhdenij. CHasto samym vazhnym sredstvom proektirovaniya okazyvaetsya
prostaya grifel'naya doska; bez nee idei proekta, nahodyashchiesya v
zarodyshe, ne mogut razvit'sya i stat' obshchim dostoyaniem v srede
razrabotchikov i programmistov.
     Pohozhe, chto samyj populyarnyj sposob provedeniya eksperimenta svoditsya
k postroeniyu prototipa, t.e. umen'shennoj versii sistemy. Prototip ne
obyazan udovletvoryat' harakteristikam real'nyh sistem, obychno v
izobilii est' mashinnye resursy i programmnaya podderzhka, i v takih
usloviyah programmisty i razrabotchiki stanovyatsya neprivychno opytnymi,
horosho obrazovannymi i aktivnymi. Poyavlyaetsya cel' - sdelat'
rabo