tayushchij prototip kak mozhno skoree, chtoby nachat' issledovanie
variantov proekta i sposobov realizacii.
      Takoj podhod, esli primenyat' ego razumno, mozhet privesti k
uspehu. No on takzhe mozhet sluzhit' opravdaniem neudachno sdelannyh
sistem. Delo v tom, chto udelyaya osoboe vnimanie prototipu, mozhno
prijti k smeshcheniyu usilij ot "issledovanie variantov
proekta" k "poluchenie kak mozhno skoree rabochej versii sistemy".
Togda bystro ugasnet interes k vnutrennej strukture prototipa
("ved' eto tol'ko prototip"), a rabota po proektirovaniyu budet
vytesnyat'sya manipulirovaniem s realizaciej prototipa.  Proschet
zaklyuchaetsya v tom, chto takaya realizaciya mozhet legko privesti k sisteme,
kotoraya imeet vid "pochti zakonchennoj", a po suti yavlyaetsya pozhiratelem
resursov i koshmarom dlya teh, kto ee soprovozhdaet. V etom
sluchae na prototip tratyatsya vremya i energiya, kotorye luchshe priberech'
dlya real'noj sistemy. Dlya razrabotchikov i menedzherov est' iskushenie
peredelat' prototip v konechnyj programmnyj produkt, a "iskusstvo
nastrojki sistemy" otlozhit' do vypuska sleduyushchej versii. Esli idti
takim putem, to prototipy otricayut vse osnovy proektirovaniya.
     Shodnaya problema voznikaet, esli issledovateli privyazyvayutsya
k tem sredstvam, kotorye oni sozdali pri postroenii prototipa,
i zabyvayut, chto oni mogut okazat'sya neprigodnymi dlya
rabochej sistemy, i chto svoboda ot ogranichenij i formal'nostej, k
kotoroj oni privykli, rabotaya v nebol'shoj gruppe, mozhet okazat'sya
nevozmozhnoj v bol'shom kollektive, b'yushchimsya nad ustraneniem dlinnoj
cepi prepyatstvij.
      I v to zhe vremya sozdanie prototipov mozhet sygrat' vazhnuyu rol'.
Rassmotrim, naprimer, proektirovanie pol'zovatel'skogo interfejsa. Dlya
etoj zadachi vnutrennyaya struktura toj chasti sistemy, kotoraya pryamo ne
obshchaetsya s pol'zovatelem, obychno ne vazhna, i ispol'zovanie prototipov -
eto edinstvennyj sposob uznat',
kakova budet reakciya pol'zovatelya pri rabote s sistemoj.
Drugim primerom sluzhat prototipy, pryamo prednaznachennye dlya izucheniya
vnutrennej struktury sistemy. Zdes' uzhe interfejs s pol'zovatelem
mozhet byt' primitivnym, vozmozhna rabota s model'yu pol'zovatelej.
    Ispol'zovanie prototipov - eto sposob eksperimentirovaniya.
Ozhidaemyj rezul'tat - eto bolee glubokoe ponimanie celej, a ne
sam prototip. Vozmozhno, sushchnost' prototipa zaklyuchaetsya v tom,
chto on yavlyaetsya nastol'ko nepolnym, chto mozhet sluzhit' lish' sredstvom
dlya eksperimenta, i ego nel'zya prevratit' v konechnyj produkt bez
bol'shih zatrat na pereproektirovanie i na druguyu realizaciyu. Ostavlyaya
prototip "nepolnym", my tem samym pereklyuchaem vnimanie na
eksperiment i umen'shaem opasnost' prevrashcheniya prototipa v zakonchennyj
produkt. |to takzhe pochti izbavlyaet ot iskusheniya vzyat' za osnovu
proekta sistemy proekt prototipa, pri etom zabyvaya ili ignoriruya te
ogranicheniya, kotorye vnutrenne prisushchi prototipu. Posle eksperimenta
prototip nado prosto vybrosit'.
    Ne sleduet zabyvat' o drugih sposobah provedeniya eksperimenta,
kotorye mogut sluzhit' vo mnogih sluchayah al'ternativoj sozdaniyu prototipa,
i tam, gde oni primenimy, ih ispol'zovanie predpochtitel'nee, poskol'ku
oni obladayut bol'shej tochnost'yu i trebuyut men'shih zatrat
vremeni razrabotchika i resursov sistemy. Primerami mogut sluzhit'
matematicheskie modeli i razlichnye formy modelirovaniya. Po suti,
sushchestvuet beskonechnaya vozrastayushchaya posledovatel'nost',
nachinaya ot matematicheskih modelej,
ko vse bolee i bolee detal'nym sposobam modelirovaniya, zatem k
prototipam, k chastichnym realizaciyam sistemy, vplot' do polnoj sistemy.
    |to podvodit k idee postroeniya sistemy, ishodya iz nachal'nogo
proekta i realizacii, i dvigayas' putem povtornogo prohozhdeniya
etapov proektirovaniya i realizacii. |to ideal'naya strategiya,
no ona pred座avlyaet vysokie trebovaniya k sredstvam proektirovaniya
i realizacii, i v nej soderzhitsya opredelennyj risk togo, chto
programmnyj ob容m, realizuyushchij resheniya, prinyatye
pri nachal'nom proektirovanii, v processe razvitiya vyrastet do takoj
velichiny, chto sushchestvennoe uluchshenie proekta budet prosto nevozmozhno.
    Pohozhe, chto po krajnej mere teper' takuyu strategiyu primenyayut
ili v proektah ot malogo do srednego razmerov, t.e. tam, gde
maloveroyatny peredelki obshchego proekta, ili zhe dlya pereproektirovaniya
i inoj realizacii posle vydachi pervonachal'noj versii sistemy, gde
ukazannaya strategiya stanovitsya neizbezhnoj.
    Pomimo eksperimentov, prednaznachennyh dlya ocenki reshenij,
prinimaemyh na etape proektirovaniya, istochnikom polucheniya poleznoj
informacii mozhet byt' analiz sobstvenno proektirovaniya i (ili)
realizacii. Naprimer, mozhet okazat'sya poleznym izuchenie razlichnyh
zavisimostej mezhdu klassami (sm.$$ 12.2), ne sleduet zabyvat' i o
takih tradicionnyh vspomogatel'nyh sredstvah realizacii, kak
graf vyzovov funkcij, ocenka proizvoditel'nosti i t.p.
    Zametim, chto specifikaciya (rezul'tat analiza sistemy) i proekt
mogut soderzhat' oshibki, kak i realizaciya, i vozmozhno, oni dazhe
bol'she podverzheny oshibkam, t.k. yavlyayutsya menee tochnymi, ne mogut byt'
provereny na praktike i obychno ne okruzheny takimi razvitymi sredstvami,
kak te, chto sluzhat dlya analiza i proverki realizacii. Vvedenie
bol'shej formalizacii v yazyk ili zapis', s pomoshch'yu kotoroj izlozhen proekt,
v kakoj-to stepeni oblegchaet ispol'zovaniya etih sredstv dlya
proektirovaniya. No, kak skazano v $$12.1.1, eto nel'zya delat'
za schet uhudsheniya yazyka, ispol'zuemogo dlya realizacii. K tomu
zhe formal'naya zapis' mozhet sama stat' istochnikom trudnostej i
problem. |to proishodit, kogda vybrannaya stepen' formalizacii ploho
podhodit dlya konkretnyh zadach, kogda strogost' formalizacii prevoshodit
matematicheskuyu osnovu sistemy i kvalifikaciyu razrabotchikov i
programmistov, i kogda formal'noe opisanie sistemy nachinaet
rashodit'sya s real'noj sistemoj, dlya kotoroj ono prednaznachalos'.
     Zaklyuchenie o neobhodimosti opyta i o tom, chto proektirovanie
neizbezhno soprovozhdaetsya oshibkami i ploho podderzhano programmnymi
sredstvami, sluzhit osnovnym dovodom v pol'zu iterativnoj modeli
proektirovaniya i realizacii. Al'ternativa - eto linejnaya model'
processa razvitiya, nachinaya s analiza i konchaya testirovaniem, no
ona sushchestvenno defektna, poskol'ku ne dopuskaet povtornyh
prohodov, ishodya iz opyta, poluchennogo na razlichnyh etapah razvitiya
sistemy.


        11.3.5 Testirovanie

Programma, kotoraya ne proshla testirovanie, ne rabotaet. Ideal, chtoby
posle proektirovaniya i (ili) verifikacii programma zarabotala s
pervogo raza, nedostizhim dlya vseh, za isklyucheniem samyh trivial'nyh
programm. Sleduet stremit'sya k idealu, no ne zabluzhdat'sya, chto
testirovanie prostoe delo.
      "Kak provodit' testirovanie?" - na etot vopros nel'zya otvetit'
v obshchem sluchae. Odnako, vopros "Kogda nachinat' testirovanie?" imeet
takoj otvet - na samom rannem etape, gde eto vozmozhno. Strategiya
testirovaniya dolzhna byt' razrabotana kak chast' proekta i vklyuchena
v realizaciyu, ili, po krajnej mere, razrabatyvat'sya parallel'no
s nimi. Kak tol'ko poyavlyaetsya rabotayushchaya sistema, nado nachinat'
testirovanie. Otkladyvanie testirovaniya do "provedeniya polnoj
realizacii" - vernyj sposob vyjti iz grafika ili peredat' versiyu
s oshibkami.
     Vsyudu, gde eto vozmozhno, proektirovanie dolzhno vestis' tak,
chtoby testirovat' sistemu bylo dostatochno prosto. V chastnosti,
imeet smysl sredstva testirovaniya pryamo vstraivat' v sistemu.
Inogda eto ne delaetsya iz-za boyazni slishkom ob容mnyh proverok na
stadii vypolneniya, ili iz-za opasenij, chto izbytochnost', neobhodimaya
dlya polnogo testirovaniya, izlishne uslozhnit struktury dannyh.
Obychno takie opaseniya neopravdany, poskol'ku sobstvenno programmy
proverki i dopolnitel'nye konstrukcii, neobhodimye dlya nih,
mozhno pri neobhodimosti udalit' iz sistemy pered ee postavkoj
pol'zovatelyu. Inogda mogut prigoditsya utverzhdeniya o svojstvah
programmy (sm. $$12.2.7).
    Bolee vazhnoj, chem nabor testov, yavlyaetsya podhod, kogda
struktura sistemy takova, chto est' real'nye shansy ubedit' sebya
i pol'zovatelej, chto oshibki mozhno isklyuchit' s pomoshch'yu opredelennogo
nabora staticheskih proverok, staticheskogo analiza i testirovaniya.
Esli razrabotana strategiya postroeniya sistemy, ustojchivoj k oshibkam
(sm.$$9.8), strategiya testirovaniya obychno razrabatyvaetsya kak
vspomogatel'naya.
    Esli voprosy testirovaniya polnost'yu ignoriruyutsya na etape
proektirovaniya, vozniknut problemy s testirovaniem, vremenem
postavki i soprovozhdeniem sistemy. Luchshe vsego nachat' rabotat'
nad strategiej testirovaniya s interfejsov klassov i ih
vzaimozavisimostej (kak predlagaetsya v $$12.2 i $$12.4).
    Trudno opredelit' neobhodimyj ob容m testirovaniya. Odnako,
ochevidno, chto problemu predstavlyaet nedostatok testirovaniya,
a ne ego izbytok. Skol'ko imenno resursov v sravnenii s proektirovaniem
i realizaciej sleduet otvesti dlya testirovaniya zavisit ot
prirody sistemy i metodov ee postroeniya. Odnako, mozhno predlozhit'
sleduyushchee pravilo: otvodit' bol'she resursov vremeni i chelovecheskih
usilij na testirovanie sistemy, chem na polucheniya ee pervoj realizacii.

        11.3.6 Soprovozhdenie

"Soprovozhdenie programmnogo obespecheniya" - neudachnyj termin. Slovo
"soprovozhdenie" predlagaet nevernuyu analogiyu s apparaturoj. Programmy
ne trebuyut smazki, ne imeyut dvizhushchihsya chastej, kotorye iznashivayutsya
tak, chto trebuyut zameny, u nih net treshchin, v kotorye popadaet
voda, vyzyvaya rzhavchinu. Programmy mozhno vosproizvodit' v tochnosti
i peredavat' v techenii minuty na dlinnye rasstoyaniya. Koroche,
programmy eto sovsem ne to, chto apparatura. (V originale:
"Software is not hardware").
    Deyatel'nost', kotoraya oboznachaetsya, kak soprovozhdenie programm,
na samom dele, sostoit iz pereproektirovaniya i povtornoj realizacii,
a znachit vhodit v obychnyj cikl razvitiya programmnogo obespecheniya.
Esli v proekte uchteny voprosy rasshiryaemosti, gibkosti i perenosimosti,
to obychnye zadachi soprovozhdeniya reshayutsya estestvennym obrazom.
    Podobno testirovaniyu zadachi soprovozhdeniya ne dolzhny reshat'sya
vne osnovnogo napravleniya razvitiya proekta i ih ne sleduet otkladyvat'
na potom.

        11.3.7 |ffektivnost'

D. Knutu prinadlezhit utverzhdenie "Neprodumannaya optimizaciya - koren'
vseh bed". Nekotorye slishkom horosho ubedilis' v spravedlivosti etogo
i schitayut vrednymi vse zaboty ob optimizacii. Na samom dele voprosy
effektivnosti nado vse vremya imet' v vidu vo vremya proektirovaniya i
realizacii. |to ne oznachaet, chto razrabotchik dolzhen zanimat'sya
zadachami lokal'noj optimizacii, tol'ko zadacha optimizacii na samom
global'nom urovne dolzhna ego volnovat'.
    Luchshij sposob dobit'sya effektivnosti - eto sozdat' yasnyj i
prostoj proekt. Tol'ko takoj proekt mozhet ostat'sya otnositel'no
ustojchivym na ves' period razvitiya i posluzhit' osnovoj dlya
nastrojki sistemy s cel'yu povysheniya proizvoditel'nosti. Zdes'
vazhno izbezhat' "gargantyualizma", kotoryj yavlyaetsya proklyatiem
bol'shih proektov. Slishkom chasto lyudi dobavlyayut opredelennye
vozmozhnosti sistemy "na vsyakij sluchaj" (sm. $$11.3.3.2 i $$11.4.3),
udvaivaya, uchetveryaya razmer vypolnyaemoj programmy radi zavitushek.
Eshche huzhe to, chto takie uslozhnennye sistemy trudno poddayutsya
analizu, a po etomu trudno otlichit' izbytochnye nakladnye rashody
ot neobhodimyh i provesti analiz i optimizacii na obshchem urovne.
Optimizaciya dolzhna byt' rezul'tatom analiza i ocenki proizvoditel'nosti
sistemy, a ne proizvol'nym manipulirovaniem s programmnym kodom,
prichem eto osobenno spravedlivo dlya bol'shih sistem, gde intuiciya
razrabotchika ili programmista ne mozhet sluzhit' nadezhnym ukazatelem
v voprosah effektivnosti.
       Vazhno izbegat' po suti neeffektivnyh konstrukcij, a tak zhe
takih konstrukcij, kotorye mozhno dovesti do priemlemogo urovnya
vypolneniya, tol'ko zatrativ massu vremeni i usilij. Po etoj zhe
prichine vazhno svesti k minimumu ispol'zovanie neperenosimyh po
svoej suti konstrukcij i sredstv, poskol'ku ih nalichie prepyatstvuet
rabote sistemy na drugih mashinah (menee moshchnyh, menee dorogih).

        11.4 Upravlenie proektom

Esli tol'ko eto imeet kakoj-to smysl, bol'shinstvo lyudej delaet to,
chto ih pooshchryayut delat'. Tak, v kontekste programmnogo proekta, esli
menedzher pooshchryaet opredelennye sposoby dejstvij i nakazyvaet za
drugie, redkie programmisty ili razrabotchiki risknut svoim
polozheniem, vstrechaya soprotivleniya ili bezrazlichiya administracii,
chtoby delat' tak, kak oni polagayut nuzhnymX.

X Organizaciya, v kotoroj schitayut svoih programmistov nedoumkami,
ochen' skoro poluchit programmistov, kotorye budut rady i sposobny
dejstvovat' tol'ko kak nedoumki.

Otsyuda sleduet, chto menedzher dolzhen pooshchryat' takie struktury,
kotorye sootvetstvuyut sformulirovannym celyam proekta i realizacii.
Odnako na praktike slishkom chasto byvaet inache. Sushchestvennoe
izmenenie stilya programmirovaniya dostizhimo tol'ko pri sootvetstvuyushchem
izmenenii v stile proektirovaniya, krome togo, obychno i to i drugoe
trebuet izmeneniya v stile upravleniya. Myslitel'naya i organizacionnaya
inerciya slishkom prosto svodyat vse k lokal'nym izmeneniyam, hotya
tol'ko global'nye izmeneniya mogut prinesti uspeh. Prekrasnoj
illyustraciej sluzhit perehod na yazyk s ob容ktno-orientirovannym
programmirovaniem, naprimer na S++, kogda on ne vlechet za soboj
sootvetstvuyushchih izmenenij v metodah proektirovaniya, chtoby
vospol'zovat'sya novymi vozmozhnostyami yazyka (sm. $$12.1), i, naoborot,
kogda perehod na "ob容ktno-orientirovannoe proektirovanie" ne
soprovozhdaetsya perehod na yazyk realizacii, kotoryj podderzhivaet
etot stil'.

        11.4.1 Povtornoe ispol'zovanie

CHasto osnovnoj prichinoj perehoda na novyj yazyk ili novyj metod
proektirovaniya nazyvayut to, chto eto oblegchaet povtornoe ispol'zovanie
programm ili proekta. Odnako, vo mnogih organizaciyah pooshchryayut
sotrudnika ili gruppu, kogda oni predpochitayut izobretat' koleso.
Naprimer, esli proizvoditel'nost' programmista izmeryaetsya chislom
strok programmy, to budet li on pisat' malen'kie programmy,
rabotayushchie so standartnymi bibliotekami, za schet svoego dohoda
i, mozhet byt', polozheniya? A menedzher, esli on oplachivaetsya
proporcional'no chislu lyudej v ego gruppe, budet li on ispol'zovat'
programmy, sdelannye drugimi kollektivami, esli on mozhet prosto
nanyat' eshche paru programmistov v svoyu gruppu? Kompaniya mozhet
poluchit' pravitel'stvennyj kontrakt, v kotorom ee dohod sostavlyaet
fiksirovannyj procent ot rashodov na proekt, budet li ona
sokrashchat' svoj dohod za schet ispol'zovaniya naibolee effektivnyh
sredstv? Trudno obespechit' voznagrazhdenie za povtornoe ispol'zovanie,
no esli administraciya ne najdet sposobov pooshchreniya i voznagrazhdeniya,
to ego prosto ne budet.
      Povtornoe ispol'zovanie yavlyaetsya prezhde vsego social'nym
faktorom. Povtornoe ispol'zovanie programmy vozmozhno pri uslovii,
chto
   [1] ona rabotaet; nel'zya ispol'zovat' povtorno, esli eto nevozmozhno
       i v pervyj raz;
   [2] ona ponyatna; zdes' imeet znachenie struktura programmy, nalichie
       kommentariev, dokumentacii, rukovodstva;
   [3] ona mozhet rabotat' vmeste s programmami, kotorye ne sozdavalis'
       special'no s takim usloviem;
   [4] mozhno rasschityvat' na ee soprovozhdenie (ili pridetsya delat'
       eto samomu, chto obychno ne hochetsya);
   [5] eto vygodno (hotya mozhno i razdelit' rashody po razrabotke
       i soprovozhdeniyu s drugimi pol'zovatelyami) i, nakonec;
   [6] ee mozhno najti.
K etomu mozhno eshche dobavit', chto komponent ne yavlyaetsya povtorno
ispol'zuemym, poka kto-to dejstvitel'no ne sdelal eto. Obychno zadacha
prisposobleniya komponenta k sushchestvuyushchemu okruzheniyu privodit k
utochneniyu nabora operacij, obobshcheniyu ego povedeniya, i povysheniyu ego
sposobnosti adaptacii k drugim programmam. Poka vse eto ne prodelano
hotya by odin raz, neozhidannye ostrye ugly nahodyatsya dazhe u
komponentov, kotorye tshchatel'no proektirovalis' i realizovyvalis'.
      Lichnyj opyt podskazyvaet, chto usloviya dlya povtornogo
ispol'zovaniya voznikayut tol'ko v tom sluchae, kogda nahoditsya
konkretnyj chelovek, zanyatyj etim voprosom. V malen'kih gruppah
eto obychno byvaet tot, kto sluchajno ili zaplanirovanno okazyvaetsya
hranitelem obshchih bibliotek ili dokumentacii. V bol'shih organizaciyah
eto byvaet gruppa ili otdel, kotorye poluchayut privilegiyu sobirat',
dokumentirovat', populyarizirovat' i soprovozhdat' programmnoe
obespechenie, ispol'zuemoe razlichnymi gruppami.
      Nel'zya nedoocenivat' takie gruppy "standartnyh komponentov".
Ukazhem, chto v pervom priblizhenii, sistema otrazhaet organizaciyu,
kotoraya ee sozdala. Esli v organizacii net sredstv pooshchreniya i
voznagrazhdeniya kooperacii i razdeleniya truda, to i na praktike
oni budut isklyucheniem. Gruppa standartnyh komponentov dolzhna
aktivno predlagat' svoi komponenty. Obychnaya tradicionnaya
dokumentaciya vazhna, no ee nedostatochno. Pomimo etogo ukazannaya
gruppa dolzhna predostavlyat' rukovodstva i druguyu informaciyu,
kotoraya pozvolit potencial'nomu pol'zovatelyu otyskat' komponent i
ponyat' kak on mozhet emu pomoch'. Znachit eta gruppa dolzhna predprinimat'
dejstviya, kotorye obychno svyazyvayutsya s sistemoj obrazovaniya i
marketinga. CHleny gruppy komponentov dolzhny vsegda, kogda eto
vozmozhno, rabotat' v tesnom sotrudnichestve s razrabotchikami iz
oblastej prilozheniya. Tol'ko togda oni budut v kurse zaprosov
pol'zovatelej i sumeyut pochuyat' vozmozhnosti ispol'zovaniya
standartnogo komponenta v razlichnyh oblastyah. |to yavlyaetsya
argumentom za ispol'zovanie takoj gruppy v roli konsul'tanta i v
pol'zu vnutrennih postavok programm, chtoby informaciya iz gruppy
komponentov mogla svobodno rasprostranyat'sya.
      Zametim, chto ne vse programmy dolzhny byt' rasschitany na
povtornoe ispol'zovanie, inymi slovami, povtornoe ispol'zovanie ne
yavlyaetsya universal'nym svojstvom. Skazat', chto nekotoryj komponent
mozhet byt' povtorno ispol'zovan, oznachaet, chto v ramkah opredelennoj
struktury ego povtornoe ispol'zovanie ne potrebuet znachitel'nyh
usilij. No v bol'shinstve sluchaev perenos v druguyu strukturu mozhet
potrebovat' bol'shoj raboty. V etom smysle povtornoe ispol'zovanie
sil'no napominaet perenosimost'. Vazhno ponimat', chto povtornoe
ispol'zovanie yavlyaetsya rezul'tatom proektirovaniya, stavivshego
takuyu cel', modifikacii komponentov na osnove opyta i special'nyh
usilij, predprinyatyh dlya poiska sredi sushchestvuyushchih komponentov
kandidatov na povtornoe ispol'zovanie. Neosoznannoe ispol'zovanie
sredstv yazyka ili priemov programmirovaniya ne mozhet chudesnym
obrazom garantirovat' povtornoe ispol'zovanie. Takie sredstva yazyka
S++, kak klassy, virtual'nye funkcii i shablony tipa, sposobstvuyut
proektirovaniyu, oblegchayushchemu povtornoe ispol'zovanie (znachit delayut
ego bolee veroyatnym), no sami po sebe eti sredstva ne garantiruyut
povtornoe ispol'zovanie.

        11.4.2 Razmer

CHelovek i organizaciya sklonny izlishne radovat'sya tomu, chto oni
"dejstvuyut po pravil'noj metode". V institutskoj srede eto chasto
zvuchit kak "razvitie soglasno strogim predpisaniyam". V oboih sluchayah
zdravyj smysl stanovitsya pervoj zhertvoj strastnogo i chasto iskrennego
zhelaniya vnesti uluchsheniya. K neschast'yu, esli zdravogo smysla ne hvataet,
to ushcherb, nanesennyj nerazumnymi dejstviyami, mozhet byt' neogranichennym.
    Vernemsya k etapam processa razvitiya, perechislennym v $$11.3, i
k shagam proektirovaniya, ukazannym v $$11.3.3. Otnositel'no prosto
pererabotat' eti etapy v tochnyj metod proektirovaniya, kogda shag tochno
opredelen, imeet horosho opredelennye vhodnye i vyhodnye dannye i
poluformal'nuyu zapis' dlya zadaniya vhodnyh i vyhodnyh dannyh. Mozhno
sostavit' protokol, kotoromu dolzhno podchinyat'sya proektirovanie,
sozdat' sredstva, predostavlyayushchie opredelennye udobstva dlya zapisi
i organizacii processa. Dalee, issleduya klassifikaciyu zavisimostej,
privedennuyu v $$12.2, mozhno postanovit', chto opredelennye zavisimosti
yavlyayutsya horoshimi, a drugie sleduet schitat' plohimi, i predostavit'
sredstva analiza, kotorye obespechat provedenie takih ocenok vo vseh
stadiyah proekta. CHtoby zavershit' takuyu "standartizaciyu" processa
sozdaniya programm, mozhno bylo by vvesti standarty na dokumentaciyu
(v tom chisle pravila na pravopisanie i grammatiku i soglasheniya o
formate dokumentacii), a tak zhe standarty na obshchij vid programm
(v tom chisle ukazaniya kakie sredstva yazyka sleduet ispol'zovat',
a kakie net, perechislenie dopustimyh bibliotek i teh, kotorye ne nuzhno
ispol'zovat', soglasheniya ob imenovanii funkcij, tipov, peremennyh,
pravila raspolozheniya teksta programmy i t.d.).
     Vse eto mozhet sposobstvovat' uspehu proekta. Po krajnej mere,
bylo by yavnoj glupost'yu, brat'sya za proekt sistemy, kotoraya
predpolozhitel'no budet imet' poryadka desyati millionov strok teksta,
nad kotoroj budut rabotat' sotni chelovek, i kotoruyu budut
soprovozhdat' tysyachi chelovek v techenii desyatiletij, ne imeya dostatochno
horosho opredelennogo i strogogo plana po vsem perechislennym vyshe
poziciyam.
    K schast'yu, bol'shinstvo sistem ne otnositsya k etoj kategorii.
Tem ne menee, esli resheno, chto dannyj metod proektirovaniya ili
sledovanie ukazannym obrazcam v programmirovanii i dokumentacii
yavlyayutsya "pravil'nymi", to nachinaet okazyvat'sya davlenie, chtoby
primenyat' ih povsemestno. V nebol'shih proektah eto privodit k
nelepym ogranicheniyam i bol'shim nakladnym rashodam. V chastnosti,
eto mozhet privesti k tomu, chto meroj razvitiya i uspeha stanovitsya
ne produktivnaya rabota, a peresylka bumazhek i zapolnenie razlichnyh
blankov. Esli eto sluchitsya, to v takom proekte nastoyashchih
programmistov i razrabotchikov vytesnyat byurokraty.
    Kogda proishodit takoe nelepoe zloupotreblenie metodami
proektirovaniya (po vsej vidimosti sovershenno razumnymi), to neudacha
proekta stanovitsya opravdaniem otkaza ot prakticheski vsyakoj
formalizacii processa razrabotki programmnogo obespecheniya. |to,
v svoyu ochered', vedet k takoj putanice i takim provalam, kotorye
kak raz i dolzhen byl predotvratit' nadlezhashchij metod proektirovaniya.
    Osnovnaya problema sostoit v opredelenii stepeni formalizacii,
prigodnoj dlya processa razvitiya konkretnogo proekta. Ne rasschityvajte
legko najti ee reshenie. Po suti dlya malogo proekta kazhdyj metod
mozhet srabotat'. Eshche huzhe to, chto pohozhe prakticheski kazhdyj metod,
dazhe esli on ploho produman i zhestok po otnosheniyu k ispolnitelyam,
mozhet srabotat' dlya bol'shogo proekta, esli vy gotovy zatratit'
ujmu vremeni i deneg.
    V processe razvitiya programmnogo obespecheniya glavnaya zadacha -
sohranit' celostnost' proekta. Trudnost' etoj zadachi zavisit
nelinejno ot razmera proekta. Sformulirovat' i sohranit' osnovnye
ustanovki v bol'shom proekte mozhet tol'ko odin chelovek ili malen'kaya
gruppa. Bol'shinstvo lyudej tratit stol'ko vremeni na reshenie
podzadach, tehnicheskie detali, povsednevnuyu administrativnuyu rabotu,
chto obshchie celi proekta legko zabyvaet ili zamenyaet ih na bolee
lokal'nye i blizkie celi. Vernyj put' k neudache, kogda net cheloveka
ili gruppy s pryamym zadaniem sledit' za celostnost'yu proekta.
Vernyj put' k neudache, kogda u takogo cheloveka ili gruppy net
sredstv vozdejstvovat' na proekt v celom.
    Otsutstvie soglasovannyh dal'nih celej namnogo bolee opasno
dlya proekta i organizacii, chem otsutstvie kakogo-libo odnogo
konkretnogo svojstva. Nebol'shaya gruppa lyudej dolzhna sformulirovat'
takie obshchie celi, postoyanno derzhat' ih v ume, sostavit' dokumenty,
soderzhashchie samoe obshchee opisanie proekta, sostavit' poyasneniya k
osnovnym ponyatiyam, i voobshche, pomogat' vsem ostal'nym pomnit' o
naznachenii proekta.

        11.4.3 CHelovecheskij faktor

Opisannyj zdes' metod proektirovaniya rasschitan na iskusnyh
razrabotchikov i programmistov, poetomu ot ih podbora zavisit
uspeh organizacii.
    Menedzhery chasto zabyvayut, chto organizaciya sostoit iz
individuumov. Rasprostraneno mnenie, chto programmisty ravny i
vzaimozamenyaemy. |to zabluzhdenie mozhet pogubit' organizaciyu za schet
vytesneniya mnogih samyh aktivnyh sotrudnikov i prinuzhdeniya
ostal'nyh rabotat' nad zadachami znachitel'no nizhe ih urovnya.
Individuumy vzaimozamenyaemy tol'ko, esli im ne dayut primenit'
svoj talant, kotoryj podnimaet ih nad obshchim minimal'nym urovnem,
neobhodimym dlya resheniya dannoj zadachi. Poetomu mif o vzaimozamenyaemosti
beschelovechen i po suti svoej rastochitelen.
   Mnogie sistemy ocenok proizvoditel'nosti programmista pooshchryayut
rastochitel'nost' i ne mogut uchest' sushchestvennyj lichnyj vklad
cheloveka. Samym ochevidnym primerom sluzhit shiroko rasprostranennaya
praktika ocenivat' uspeh v kolichestve zaprogrammirovannyh strok,
vydannyh stranic dokumentacii, propushchennyh testov i t.p.
Takie cifry effektno vyglyadyat na diagrammah, no imeyut samoe
otdalennoe otnoshenie k dejstvitel'nosti. Naprimer, esli
proizvoditel'nost' izmeryat' chislom zaprogrammirovannyh strok, to
udachnoe povtornoe ispol'zovanie uhudshit ocenku truda programmista.
Obychno tot zhe effekt budet imet' udachnoe primenenie luchshih priemov
v processe pereproektirovaniya bol'shoj chasti sistemy.
    Kachestvo rezul'tata izmerit' znachitel'no trudnee, chem kolichestvo,
i  voznagrazhdat' ispolnitelya ili gruppu sleduet za kachestvo ih truda,
a ne na osnove grubyh kolichestvennyh ocenok. K sozhaleniyu, naskol'ko
izvestno, prakticheskaya razrabotka sposobov ocenki kachestva eshche ne
nachalas'. K tomu zhe ocenki, kotorye nepolno opisyvayut sostoyanie
proekta, mogut iskazit' process ego razvitiya. Lyudi prisposablivayutsya,
chtoby ulozhit'sya v otvedennyj srok i perestraivayut svoyu rabotu v
sootvetstvii s ocenkami proizvoditel'nosti, v rezul'tate stradaet
obshchaya celostnost' sistemy i ee proizvoditel'nost'. Naprimer, esli
otveden srok dlya vyyavleniya opredelennogo chisla oshibok, to dlya togo,
chtoby ulozhit'sya v nego, aktivno ispol'zuyut proverki na stadii
vypolneniya, chto uhudshaet proizvoditel'nost' sistemy. Obratno, esli
uchityvayutsya tol'ko harakteristiki sistemy na stadii vypolneniya, to
chislo nevyyavlennyh oshibok budet rasti pri uslovii nedostatka
vremeni u ispolnitelej. Otsutstvie horoshih i razumnyh ocenok
kachestva povyshaet trebovaniya k tehnicheskoj kvalifikacii menedzherov,
inache budet postoyannaya tendenciya pooshchryat' proizvol'nuyu aktivnost',
a ne real'nyj progress. Ne nado zabyvat', chto menedzhery tozhe lyudi,
i oni dolzhny po krajnej mere nastol'ko razbirat'sya v novyh
tehnologiyah, kak i te, kem oni upravlyayut.
    Zdes', kak i v drugih aspektah processa razvitiya programmnogo
obespecheniya, sleduet rassmatrivat' bol'shie vremennye sroki. Po suti
nevozmozhno ukazat' proizvoditel'nost' cheloveka na osnove ego
raboty za god. Odnako, mnogie sotrudniki imeyut kartochku svoih
dostizhenij za bol'shoj period, i ona mozhet posluzhit' nadezhnym ukazaniem
dlya predskazaniya ih proizvoditel'nosti. Esli ne prinimat' vo vnimanie
takie kartochki, chto i delaetsya, kogda sotrudnikov schitayut
vzaimozamenyaemymi spicami v kolese organizacii, to u menedzhera
ostayutsya tol'ko vvodyashchie v zabluzhdeniya kolichestvennye ocenki.
     Esli my rassmatrivaem tol'ko dostatochno bol'shie vremennye
sroki i otkazyvaemsya ot metodov upravleniya, rasschitannyh na
"vzaimozamenyaemyh nedoumkov", to nado priznat', chto individuumu
(kak razrabotchiku ili programmistu, tak i menedzheru) nuzhen bol'shoj
srok, chtoby dorasti do bolee interesnoj i vazhnoj raboty. Takoj
podhod ne odobryaet kak "skakanie" s mesta na mesto, tak i peredachu
raboty drugomu iz-za kar'ernyh soobrazhenij. Cel'yu dolzhen byt'
nizkij oborot klyuchevyh specialistov i klyuchevyh menedzherov. Nikakoj
menedzher ne dob'etsya uspeha bez podhodyashchih tehnicheskih znanij i
vzaimoponimaniya s osnovnymi razrabotchikami i programmistami.
V tozhe vremya, v konechnom schete nikakaya gruppa razrabotchikov ili
programmistov ne dob'etsya uspeha bez podderzhki kompetentnyh
menedzherov i bez ponimaniya hotya by osnovnyh netehnicheskih voprosov,
kasayushchihsya okruzheniya, v kotorom oni rabotayut.
    Kogda trebuetsya predlozhit' nechto novoe, na perednij plan vyhodyat
osnovnye specialisty - analitiki, razrabotchiki, programmisty. Imenno
oni dolzhny reshit' trudnuyu i kriticheskuyu zadachu vnedreniya novoj
tehnologii. |to te lyudi, kotorye dolzhny ovladet' novymi metodami i
vo mnogih sluchayah zabyt' starye privychki. |to ne tak legko. Ved'
eti lyudi sdelali bol'shoj lichnyj vklad v sozdanie staryh metodov i
svoyu reputaciyu kak specialista obosnovyvayut uspehami, poluchennymi s
pomoshch'yu staryh metodov. Tak zhe obstoit delo i s mnogimi menedzherami.
     Estestvenno u takih lyudej est' strah pered izmeneniyami. On mozhet
privesti k preuvelicheniyu problem, voznikayushchih pri izmeneniyah, i k
nezhelaniyu priznat' problemy, vyzvannye starymi metodami. Estestvenno,
s drugoj storony lyudi, vystupayushchie za izmeneniya, mogut pereocenivat'
vygody, kotorye prinesut izmeneniya, i nedoocenivat' voznikayushchie
zdes' problemy. |ti dve gruppy lyudej dolzhny obshchat'sya, oni dolzhny
nauchit'sya govorit' na odnom yazyke i dolzhny pomoch' drug drugu
razrabotat' podhodyashchuyu shemu perehoda. Al'ternativoj budet
organizacionnyj paralich i uhod samyh sposobnyh lyudej iz oboih grupp.
Tem i drugim sleduet znat', chto samye udachlivye iz "staryh vorchunov"
mogli byt' "molodymi l'vami" v proshlom godu, i esli cheloveku dali
vozmozhnost' nauchit'sya bez vsyakih izdevatel'stv, to on mozhet stat'
samym stojkim i razumnym storonnikom peremen. On budet obladat'
neocenimymi svojstvami zdorovogo skepticizma, znaniya pol'zovatelej
i ponimaniya organizacionnyh prepyatstvij. Storonniki nemedlennyh i
radikal'nyh izmenenij dolzhny osoznat', chto gorazdo chashche  nuzhen
perehod, predpolagayushchij postepennoe vnedrenie novyh metodov.
S drugoj storony, te, kto ne zhelaet peremen, dolzhny poiskat' dlya
sebya takie oblasti, gde eto vozmozhno, chem vesti ozhestochennye,
ar'ergardnye boi v toj oblasti, gde novye trebovaniya uzhe zadali
sovershenno inye usloviya dlya uspeshnogo proekta.

        11.5 Svod pravil

V etoj glave my zatronuli mnogo tem, no kak pravilo ne davali
nastoyatel'nyh i konkretnyh rekomendacij po proektirovaniyu. |to
sootvetstvuet moemu ubezhdeniyu, chto net "edinstvenno vernogo resheniya".
Principy i priemy sleduet primenyat' tem sposobom, kotoryj luchshe
podhodit dlya konkretnyh zadach. Dlya etogo nuzhen vkus, opyt i razum.
Vse-taki mozhno ukazat' nekotoryj svod pravil, kotoryj razrabotchik
mozhet ispol'zovat' v kachestve orientirov, poka ne naberetsya dostatochno
opyta, chtoby vyrabotat' luchshie. Nizhe priveden svod takih pravil.
     |ti pravila mozhno ispol'zovat' v kachestve otpravnoj tochki v
processe vyrabotki osnovnyh napravlenij dlya proekta ili organizacii
ili v kachestve proverochnogo spiska. Podcherknu eshche raz, chto oni ne
yavlyayutsya universal'nymi pravilami i ne mogut zamenit' razmyshleniya.
   - Uznajte, chto vam predstoit sozdat'.
   - Stav'te opredelennye i osyazaemye celi.
   - Ne pytajtes' s pomoshch'yu tehnicheskih priemov reshit' social'nye
     problemy.
   - Rasschityvajte na bol'shoj srok
     - v proektirovanii, i
     - upravlenii lyud'mi.
   - Ispol'zujte sushchestvuyushchie sistemy v kachestve modelej, istochnika
     vdohnoveniya i otpravnoj tochki.
   - Proektirujte v raschete na izmeneniya:
     - gibkost',
     - rasshiryaemost',
     - perenosimost', i
     - povtornoe ispol'zovanie.
   - Dokumentirujte, predlagajte i podderzhivajte povtorno ispol'zuemye
     komponenty.
   - Pooshchryajte i voznagrazhdajte povtornoe ispol'zovanie
     - proektov,
     - bibliotek, i
     - klassov.
   - Sosredotoch'tes' na proektirovanii komponenty.
     - Ispol'zujte klassy dlya predstavleniya ponyatij.
     - Opredelyajte interfejsy tak, chtoby sdelat' otkrytym minimal'nyj
       ob容m informacii, trebuemoj dlya interfejsa.
     - Provodite stroguyu tipizaciyu interfejsov vsegda, kogda eto
       vozmozhno.
     - Ispol'zujte v interfejsah tipy iz oblasti prilozheniya vsegda,
       kogda eto vozmozhno.
   - Mnogokratno issledujte i utochnyajte kak proekt, tak i realizaciyu.
   - Ispol'zujte luchshie dostupnye sredstva dlya proverki i analiza
     - proekta, i
     - realizacii.
   - |ksperimentirujte, analizirujte i provodite testirovanie na
     samom rannem vozmozhnom etape.
   - Stremites' k prostote, maksimal'noj prostote, no ne sverh togo.
   - Ne razrastajtes', ne dobavlyajte vozmozhnosti "na vsyakij sluchaj".
   - Ne zabyvajte ob effektivnosti.
   - Sohranyajte uroven' formalizacii, sootvetstvuyushchim razmeru proekta.
   - Ne zabyvajte, chto razrabotchiki, programmisty i dazhe menedzhery
     ostayutsya lyud'mi.
Eshche nekotorye pravila mozhno najti v $$12.5

        11.6 Spisok literatury s kommentariyami

V etoj glave my tol'ko poverhnostno zatronuli voprosy proektirovaniya
i upravleniya programmnymi proektami. Po etoj prichine nizhe predlagaetsya
spisok literatury s kommentariyami. Znachitel'no bolee obshirnyj spisok
literatury s kommentariyami mozhno najti v [2].
[1] Bruce Anderson and Sanjiv Gossain: An Iterative Design Model for
    Reusable Object-Oriented Software. Proc. OOPSLA'90. Ottawa,
    Canada. pp. 12-27.
    Opisanie modeli iterativnogo proektirovaniya i povtornogo
    proektirovaniya s nekotorymi primerami i obsuzhdeniem rezul'tatov.
[2] Grady Booch: Object Oriented Design. Benjamin Cummings. 1991.
    V etoj knige est' detal'noe opisanie proektirovaniya, opredelennyj
    metod proektirovaniya s graficheskoj formoj zapisi i neskol'ko
    bol'shih primerov proekta, zapisannyh na razlichnyh yazykah. |to
    prevoshodnaya kniga, kotoraya vo mnogom povliyala na etu glavu. V nej
    bolee gluboko rassmatrivayutsya mnogie iz zatronutyh zdes' voprosov.
[3] Fred Brooks: The Mythical Man Month. Addison Wesley. 1982.
    Kazhdyj dolzhen perechityvat' etu knigu raz v paru let.
    Predosterezhenie ot vysokomeriya. Ona neskol'ko ustarela v
    tehnicheskih voprosah, no sovershenno ne ustarela vo vsem, chto
    kasaetsya otdel'nogo rabotnika, organizacii i voprosov razmera.
[4] Fred Brooks: No Silver Bullet. IEEE Computer, Vol.20 No.4.
    April 1987.
    Svodka razlichnyh podhodov k processu razvitiya bol'shih programmnyh
    sistem s ochen' poleznym predosterezheniem ot very v magicheskie
    recepty ("zolotaya pulya").
[5] De Marco and Lister: Peopleware. Dorset House Publishing Co. 1987.
    Odna iz nemnogih knig, posvyashchennyh roli chelovecheskogo faktora
    v proizvodstve programmnogo obespecheniya. Neobhodima dlya kazhdogo
    menedzhera. Dostatochno uspokaivayushchaya dlya chteniya pered snom.
    Lekarstvo ot mnogih glupostej.
[6] Ron Kerr: A Materialistic View of the Software "Engineering"
    Analogy. in SIGPLAN Notices, March 1987. pp 123-125.
    Ispol'zovanie analogii v etoj i sleduyushchej glavah vo mnogom
    obyazano nablyudeniyam iz ukazannoj stat'i, a tak zhe besedam s
    R. Kerrom, kotorye etomu predshestvovali.
[7] Barbara Liskov: Data Abstraction and Hierarchy. Proc. OOPSLA'87
    (Addendum). Orlando, Florida. pp 17-34.
    Issleduetsya kak ispol'zovanie nasledovaniya mozhet povredit'
    koncepcii abstraktnyh dannyh. Ukazhem, chto v S++ est' special'nye
    yazykovye sredstva, pomogayushchie izbezhat' bol'shinstvo ukazannyh
    problem ($$12.2.5).
[8] C. N. Parkinson: Parkinson's Law and other Studies in
    Administration. Houghton-Mifflin. Boston. 1957.
    Odno iz zabavnyh i samyh yazvitel'nyh opisanij bed, k kotorym
    privodit process administrirovaniya.
[9] Bertrand Meyer: Object Oriented Software Construction.
    Prentice Hall. 1988.
    Stranicy 1-64 i 323-334 soderzhat horoshee opisanie odnogo vzglyada
    na ob容ktno-orientirovannoe programmirovanie i proektirovanie,
    a takzhe mnogo zdravyh, prakticheskih sovetov. V ostal'noj chasti
    knigi opisyvaetsya yazyk |jffel' (Eiffel).
[10] Alan Snyder: Encapsulation and Inheritance in Object-Oriented
    Programming Languages. Proc. OOPSLA'86. Portland, Oregon. pp.38-45.
    Vozmozhno pervoe horoshee opisanie vzaimodejstviya obolochki i
    nasledovaniya. V stat'e tak zhe na horoshem urovne rassmatrivayutsya
    nekotorye ponyatiya, svyazannye s mnozhestvennym nasledovaniem.
[11] Rebecca Wirfs-Brock, Brian Wilkerson, and Lauren Wiener:
    Designing Object-Oriented Software. Prentice Hall. 1990.
    Opisyvaetsya antropomorfnyj metod proektirovaniya osnovannyj na
    special'nyh kartochkah CRC (Classes, Responsibilities,
    Collaboration) (t.e. Klassy, Otvetstvennost', Sotrudnichestvo).
    Tekst, a mozhet byt' i sam metod tyagoteet k yazyku Smalltalk.




         * PROEKTIROVANIE I S++

        Stremis' k prostote, maksimal'noj prostote, no ne sverh togo.
         - A. |jnshtejn
|ta glava  posvyashchena svyazi mezhdu proektirovaniem i yazykom
programmirovaniya S++. V nej issleduetsya primenenie klassov pri
proektirovanii i ukazyvayutsya opredelennye vidy zavisimostej, kotorye
sleduet vydelyat' kak vnutri klassa, tak i mezhdu klassami. Izuchaetsya
rol' staticheskogo kontrolya tipov. Issleduetsya primenenie nasledovaniya
i svyaz' nasledovaniya i prinadlezhnosti. Obsuzhdaetsya ponyatie komponenta
i dayutsya nekotorye obrazcy dlya interfejsov.

        12.1 Proektirovanie i yazyk programmirovaniya.

Esli by mne nado bylo postroit' most, to ya ser'ezno podumal by, iz
kakogo materiala ego stroit', i proekt mosta sil'no zavisel by ot
vybrannogo materiala, a, sledovatel'no, razumnye proekty kamennogo
mosta otlichayutsya ot razumnyh proektov metallicheskogo mosta ili
ot razumnyh proektov derevyannogo mosta i t.d. Ne stoit
rasschityvat' na vybor podhodyashchego dlya mosta materiala bez opredelennyh
znanij o materialah i ih ispol'zovanii. Konechno, vam ne nado byt'
specialistom plotnikom dlya proektirovaniya derevyannogo mosta, no vy
dolzhny znat' osnovy konstruirovaniya iz dereva, chtoby predpochest' ego
metallu v kachestve materiala dlya mosta. Bolee togo, hotya dlya
proektirovaniya derevyannogo mosta vy i ne dolzhny byt' specialistom
plotnikom, vam neobhodimo dostatochno detal'no znat' svojstva
dereva i eshche bol'she znat' o plotnikah.
    Analogichno, pri vybore yazyka programmirovaniya dlya
opredelennogo programmnogo obespecheniya nado znat' neskol'ko yazykov,
a dlya uspeshnogo proektirovaniya programmy nado dostatochno detal'no
znat' vybrannyj yazyk realizacii, dazhe esli vam lichno ne predstoit
napisat' ni odnoj strochki programmy. Horoshij proektirovshchik mosta
cenit svojstva ispol'zuemyh im materialov i primenyaet ih dlya uluchsheniya
proekta. Analogichno, horoshij razrabotchik programm ispol'zuet sil'nye
storony yazyka realizacii i, naskol'ko vozmozhno, stremitsya izbezhat' takogo
ego ispol'zovaniya, kotoroe vyzovet trudnosti na stadii realizacii.
    Mozhno podumat', chto tak poluchaetsya estestvennym obrazom, esli
v proektirovanii uchastvuet tol'ko odin razrabotchik ili programmist, odnako
dazhe v etom sluchae programmist v silu nedostatka opyta ili iz-za
neopravdannoj priverzhennosti k stilyu programmirovaniya, rasschitannomu na
sovershenno drugie yazyki, mozhet sbit'sya na nevernoe ispol'zovanie yazyka.
Esli razrabotchik sushchestvenno otlichaetsya ot programmista,  osobenno
esli u nih raznaya programmistskaya kul'tura, vozmozhnost' poyavleniya
v okonchatel'noj versii sistemy oshibok, neeffektivnyh i neelegantnyh reshenij
pochti navernyaka prevratitsya v neizbezhnost'.
    Itak, chem mozhet pomoch' razrabotchiku yazyk programmirovaniya? On
mozhet predostavit' takie yazykovye sredstva, kotorye pozvolyat
vyrazit' pryamo na yazyke programmirovaniya osnovnye ponyatiya proekta.
Togda oblegchaetsya realizaciya, proshche podderzhivat' ee sootvetstvie
proektu, proshche organizovat' obshchenie mezhdu
razrabotchikami i programmistami, i poyavlyaetsya vozmozhnost' sozdat'
bolee sovershennye sredstva kak dlya razrabotchikov, tak i dlya
programmistov.
    Naprimer, mnogie metody proektirovaniya udelyayut znachitel'noe vnimanie
zavisimostyam mezhdu razlichnymi chastyami programmy (obychno s cel'yu
ih umen'sheniya i garantii togo, chto eti chasti budut ponyatny i horosho
opredeleny). YAzyk, dopuskayushchij yavnoe zadanie interfejsov mezhdu
chastyami programmy, mozhet pomoch' v etom voprose
razrabotchikam. On mozhet garantirovat', chto dejstvitel'no budut
sushchestvovat' tol'ko predpolagaemye zavisimosti. Poskol'ku
bol'shinstvo zavisimostej yavno vyrazheno v programme na takom yazyke,
mozhno razrabotat' sredstva, chitayushchie programmu i vydayushchie grafy
zavisimostej. V etom sluchae razrabotchiku i drugim ispolnitelyam legche
uyasnit' strukturu programmy. Takie yazyki programmirovaniya kak S++
pomogayut sokratit' razryv mezhdu proektom i programmoj, a znachit
umen'shayut vozmozhnost' putanicy i nedoponimanij.
     Bazovoe ponyatie S++ - eto klass. Klass imeet opredelennyj
tip. Krome togo, klass yavlyaetsya pervichnym sredstvom upryatyvaniya
informacii. Mozhno opisyvat' programmy v terminah pol'zovatel'skih
tipov i ierarhij etih tipov. Kak vstroennye, tak i pol'zovatel'skie
tipy podchinyayutsya pravilam staticheskogo kontrolya tipov. Virtual'nye
funkcii predostavlyayut, ne narushaya pravil staticheskih tipov,
mehanizm svyazyvaniya na etape vypolneniya. SHablony tipa pozvolyayut
sozdavat' parametrizovannye tipy. Osobye situacii pozvolyayut sdelat'
regulyarnoj reakciyu na oshibki. Vse eti sredstva S++ mozhno
ispol'zovat' bez dopolnitel'nyh nakladnyh
rashodov v sravnenii s programmoj na S. Takovy glavnejshie
sredstva S++, kotorye dolzhen predstavlyat' i uchityvat' razrabotchik.
Krome togo, sushchestvenno povliyat' na prinyatie reshenij na stadii
proektirovaniya mozhet nalichie  dostupnyh bol'shih bibliotek
sleduyushchego naznacheniya: dlya raboty s matricami, dlya svyazi s
bazami dannyh, dlya podderzhki parallel'nogo
programmirovaniya, graficheskie biblioteki i t.d.
      Strah pered noviznoj, neprigodnyj zdes' opyt raboty na drugih
yazykah, v drugih sistemah ili oblastyah prilozheniya, bednye sredstva
proektirovaniya - vse eto privodit k neoptimal'nomu ispol'zovaniyu S++.
Sleduet otmetit' tri momenta, kogda razrabotchiku ne udaetsya
izvlech' vygodu iz vozmozhnostej S++ i uchest' ogranicheniya yazyka:
[1] Ignorirovanie klassov i sostavlenie proekta takim obrazom, chto
    programmistam prihoditsya ogranichivat'sya tol'ko S.
[2] Ignorirovanie proizvodnyh klassov i virtual'nyh funkcij,
    ispol'zovanie tol'ko podmnozhestva abstraktnyh dannyh.
[3] Ignorirovanie staticheskogo kontrolya tipov i sostavlenie proekta
    takim obrazom, chto programmisty vynuzhdeny primenyat' dinamicheskie
    proverki tipov.
Obychno ukazannye momenty voznikayut u razrabotchikov, svyazannyh s:
[1] C, ili tradicionnoj sistemoj CASE ili metodami str