Подпишитесь на наши новости
Вернуться к началу с статьи up
 

ПРОГРАММИ́РОВАНИЕ

  • рубрика

    Рубрика: Математика

  • родственные статьи
  • image description

    В книжной версии

    Том 27. Москва, 2015, стр. 550-551

  • image description

    Скопировать библиографическую ссылку:




Авторы: В. В. Кулямин

ПРОГРАММИ́РОВАНИЕ, про­цесс соз­да­ния ком­пь­ю­тер­ных про­грамм или про­грамм­но­го обес­пе­че­ния, а так­же дис­ци­п­ли­на, изу­чаю­щая ме­то­ды и приё­мы соз­да­ния и раз­ви­тия ком­пь­ю­тер­ных про­грамм (бо­лее точ­ное назв. дис­ци­п­ли­ны – ин­же­не­рия про­грамм­но­го обес­пе­че­ния или про­грамм­ная ин­же­не­рия).

П. вклю­ча­ет: ана­лиз пред­мет­ной об­лас­ти – вы­де­ле­ние тре­бо­ва­ний к про­грам­ме и точ­ную по­ста­нов­ку ре­шае­мых за­дач; про­ек­ти­ро­ва­ние про­грам­мы – вы­де­ле­ние ком­по­нен­тов или мо­ду­лей на ос­но­ве отд. ре­шае­мых за­дач, оп­ре­де­ле­ние спо­со­бов взаи­мо­дей­ст­вий ме­ж­ду ни­ми, оп­ре­де­ле­ние ал­го­рит­мов ра­бо­ты и струк­тур дан­ных, ис­поль­зуе­мых ка­ж­дым мо­ду­лем; ко­ди­ро­ва­ние – на­писа­ние отд. мо­ду­лей на оп­ре­де­лён­ных язы­ках про­грам­ми­ро­ва­ния; вы­яв­ле­ние де­фек­тов и оши­бок при по­мо­щи тес­тиро­ва­ния (про­вер­ка про­грам­мы на на­бо­ре за­ра­нее вы­бран­ных сце­на­ри­ев, по­зво­ляю­щем оце­нить её кор­рект­ность) и др. ме­то­дов ве­ри­фи­ка­ции, а так­же от­лад­ку про­грам­мы; раз­вёр­ты­ва­ние – раз­ме­ще­ние про­грам­мы в её ра­бо­чем ок­ру­же­нии, на­строй­ка и под­го­тов­ка её к ра­бо­те, обу­че­ние поль­зо­ва­те­лей ра­бо­те с про­грам­мой; со­про­во­ж­де­ние – под­держ­ка ра­бо­то­спо­соб­но­сти, на­строй­ка под из­ме­няю­щее­ся ок­ру­же­ние, вы­яв­ле­ние де­фек­тов и но­вых за­дач, вне­се­ние ис­прав­ле­ний и из­ме­не­ний. Со­про­во­ж­де­ние иг­ра­ет осо­бую роль, по­сколь­ку мн. про­грам­мы ис­поль­зу­ют­ся в те­че­ние де­ся­ти­ле­тий и долж­ны из­ме­нять­ся в со­от­вет­ст­вии с из­ме­не­ни­ем ре­шае­мых за­дач или их мас­шта­бов, по­яв­ле­ни­ем но­вых уст­ройств или не­об­хо­ди­мо­сти во взаи­мо­дей­ст­вии с др. про­грам­ма­ми. В рам­ках со­про­во­ж­де­ния мно­го раз про­во­дит­ся пе­ре­про­ек­ти­ро­ва­ние, ко­ди­ро­ва­ние и тес­ти­ро­ва­ние, а так­же до­бав­ле­ние но­вых ком­по­нен­тов, по­это­му бо́ль­шая часть за­трат на раз­ра­бот­ку про­грам­мы па­да­ет на не­го. До­пол­нит. слож­но­сти для со­про­во­ж­де­ния и раз­ви­тия про­грамм воз­ни­ка­ют из-за раз­ме­ров и слож­но­сти совр. про­грамм­ных сис­тем, дос­ти­гаю­щих де­сят­ков млн. строк ко­да, на разл. язы­ках про­грам­ми­ро­ва­ния. Та­кие мас­шта­бы про­грамм­ных сис­тем ста­ли воз­мож­ны за счёт ис­поль­зо­ва­ния под­про­грамм и ком­по­нен­тов, по­зво­ляю­щих соз­да­вать ие­рар­хич. сис­те­мы из боль­шо­го ко­ли­че­ст­ва не­боль­ших про­грамм.

Пе­ре­чис­лен­ные ви­ды дея­тель­но­сти при П. обыч­но вы­пол­ня­ют­ся не в жё­ст­ко за­дан­ной по­сле­до­ва­тель­но­сти, а по ме­ре не­об­хо­ди­мо­сти; напр., ис­прав­ле­ние ошиб­ки, об­на­ру­жен­ной при тес­ти­ро­ва­нии, мо­жет по­тре­бо­вать до­пол­нит. ана­ли­за тре­бо­ва­ний, уточ­не­ния за­дач и вы­бо­ра др. ал­го­рит­ма ра­бо­ты со­дер­жа­ще­го ошиб­ку мо­ду­ля. Про­цес­сы раз­ра­бот­ки про­грамм­но­го обес­пе­че­ния, пред­пи­сы­ваю­щие оп­ре­де­лён­ные пра­ви­ла соз­да­ния про­грамм, с це­лью уп­ро­ще­ния пла­ни­ро­ва­ния ра­бот мо­гут на­ла­гать разл. ог­ра­ни­че­ния на воз­мож­ные по­сле­до­ва­тель­но­сти вы­пол­не­ния та­ких дей­ст­вий.

В за­ви­си­мо­сти от по­став­лен­ных це­лей, раз­мер­но­сти за­да­чи, ме­то­дов ре­ше­ния раз­ли­ча­ют па­рал­лель­ное про­грам­ми­ро­ва­ние, рас­пре­де­лён­ное про­грам­ми­ро­ва­ние и др. Сло­во «П.» ис­поль­зу­ет­ся также в не­ко­то­рых ус­то­яв­ших­ся сло­во­со­че­та­ни­ях, напр. ди­на­ми­че­ское про­грам­ми­ро­ва­ние, ли­ней­ное про­грам­ми­ро­ва­ние, ма­те­ма­ти­че­ское про­грам­ми­ро­ва­ние, где оно обыч­но яв­ля­ет­ся си­но­ни­мом сло­ва «пла­ни­ро­ва­ние». Язы­ки про­грам­ми­ро­ва­ния под­дер­жи­ва­ют разл. сти­ли П. (па­ра­диг­мы про­грам­ми­ро­ва­ния). В ис­кус­ст­во П. вхо­дит вы­бор язы­ка про­грам­ми­ро­ва­ния, наи­бо­лее пол­но под­хо­дя­ще­го для ре­ше­ния по­став­лен­ной за­да­чи.

Боль­шин­ст­во ме­то­дов и тех­нич. приё­мов П. не уни­вер­саль­ны, при­ме­ни­мы лишь для спе­ци­фич. ви­дов про­грамм (при­клад­ные, сис­тем­ные, встро­ен­ные). Од­на­ко мож­но вы­де­лить как ба­зо­вые сле­дую­щие три прин­ци­па П.: мо­дуль­ность – су­ще­ст­вен­но разл. за­да­чи долж­ны ре­шать­ся раз­ны­ми про­грамм­ны­ми ком­по­нен­та­ми, взаи­мо­дей­ст­вую­щи­ми друг с дру­гом че­рез чёт­ко оп­ре­де­лён­ные ин­тер­фей­сы, и не за­ви­сеть от внутр. ал­го­рит­мов и струк­тур дан­ных друг дру­га (см. в ст. Мо­дуль­ное про­грам­ми­ро­ва­ние); ис­поль­зо­ва­ние аб­ст­рак­ций – ре­ше­ние лю­бой за­да­чи не­об­хо­ди­мо оформ­лять в тер­ми­нах на­бо­ра сущ­но­стей, дос­та­точ­ных для опи­са­ния всех су­ще­ст­вен­ных эле­мен­тов за­да­чи и не со­дер­жа­щих лиш­ней, не­су­ще­ст­вен­ной ин­фор­ма­ции; мно­го­крат­ное ис­поль­зо­ва­ние ко­да – ка­ж­дый отд. эле­мент зна­ния о за­да­че или её ре­ше­ния дол­жен быть опи­сан од­но­крат­но, сле­ду­ет из­бе­гать дуб­ли­ро­ва­ния ин­фор­ма­ции и опи­са­ний од­них и тех же зна­ний и/или ре­ше­ний в не­сколь­ких разл. мес­тах в ко­де про­грам­мы, по­сколь­ку при из­ме­не­нии тре­бо­ва­ний ис­прав­лять та­кую про­грам­му го­раз­до слож­нее.

Пер­вым про­грам­ми­стом, на­пи­сав­шим в 1843 про­грам­му (вы­чис­ле­ние чи­сел Бер­нул­ли) для вы­чис­лит. уст­рой­ст­ва (ана­ли­ти­че­ской ма­ши­ны Ч. Бэб­бид­жа), счи­та­ет­ся гр. А. Лав­лейс. П. на пер­вых ком­пь­ю­те­рах осу­ще­ст­в­ля­лось пу­тём ус­та­нов­ки пе­ре­клю­ча­те­лей в нуж­ные по­ло­же­ния; про­грамм как та­ко­вых ещё не су­ще­ст­во­ва­ло. Пер­вая ЭВМ с хра­ни­мой в па­мя­ти про­грам­мой (реа­ли­за­ция т. н. прин­ци­пов фон Ней­ма­на) – EDSAC (1949, см. в ст. Вы­чис­ли­тель­ная ма­ши­на). Раз­ви­тие П. (в нач. 1950-х гг.) свя­за­но с пе­ре­хо­дом от на­пи­са­ния про­грамм на язы­ках ма­шин­ных ин­ст­рук­ций к бо­лее удоб­ным для вос­при­ятия че­ло­ве­ка язы­ком ас­семб­лер, а за­тем – к язы­кам вы­со­ко­го уров­ня, не­за­ви­си­мым от ар­хи­тек­ту­ры ком­пь­ю­те­ра, пер­вы­ми из ко­то­рых бы­ли фор­тран (fortran, 1954–57) и лисп (LISP, 1958, от LISt Processing language – язык об­ра­бот­ки спи­сков). Не­ко­то­рые идеи, реа­ли­зо­ван­ные в та­ких язы­ках, сфор­му­ли­ро­ва­ны А. А. Ля­пу­но­вым в его опе­ра­тор­ном ме­то­де про­грам­ми­ро­ва­ния (1953).

Как дис­ци­п­ли­на П. изу­ча­ет прин­ци­пы по­строе­ния и функ­цио­ни­ро­ва­ния про­грамм, ис­поль­зуя ме­то­ды и тех­нич. приё­мы, а так­же спо­со­бы ор­га­ни­за­ции как круп­ных про­грамм­ных сис­тем (вы­бор ар­хи­тек­ту­ры, вы­де­ле­ние ком­по­нен­тов и ор­га­ни­за­ция эф­фек­тив­но­го взаи­мо­дей­ст­вия ме­ж­ду ни­ми), так и не­боль­ших эле­мен­тов про­грамм (вы­бор ал­го­рит­мов ра­бо­ты, ор­га­ни­за­ция ко­да отд. ком­по­нен­та, ис­поль­зо­ва­ние осо­бен­но­стей язы­ков про­грам­ми­ро­ва­ния). В анг­лоя­зыч­ной лит-ре вме­сто тер­ми­на «П.» ис­поль­зу­ется «software engineering» – «про­грамм­ная ин­же­не­рия» (вве­дён в 1968 Ф. Л. Бау­эром, США). В СССР в 1970-х гг. А. П. Ер­шо­вым тер­мин пе­ре­во­дил­ся как «тех­но­ло­гия про­грам­ми­ро­ва­ния». Важ­ны­ми ве­ха­ми в раз­ви­тии дис­ци­п­ли­ны ста­ли вы­де­ле­ние по­ня­тий про­грамм­но­го мо­ду­ля и его ин­тер­фей­са ка­над. инж. Д. Пар­на­сом в 1972, чёт­кое оп­ре­де­ле­ние в нач. 1990-х гг. по­ня­тия ар­хи­тек­ту­ры про­грамм­но­го обес­пе­че­ния и по­сте­пен­но рас­ши­ряю­щее­ся при­ме­не­ние ана­ли­за про­грамм.

Лит.: Software engineering / Ed. P. Naur, B. Ran­dell. Brussels, 1969; Жу­рав­лев Ю. И. А. А. Ля­пу­нов и ста­нов­ле­ние ки­бер­не­ти­ки в на­шей стра­не // Ля­пу­нов А. А. Про­бле­мы тео­ре­ти­че­ской и при­клад­ной ки­бер­не­ти­ки. М., 1980; Allen F. E. The history of language processor technology in IBM // IBM Journal of Research and Development. 1981. Vol. 25. № 5; Zuse K. The computer, my life. B., 1993; Сом­мер­вилл И. Ин­же­не­рия про­грамм­но­го обес­пе­че­ния. 6-е изд. М., 2002; Fuegi J., Francis J. Lovelace & Babbage and the creation of the 1843 «notes» // IEEE Annals of the History of Computing. 2003. Vol. 25. № 4; Ли­па­ев В. В. Про­грамм­ная ин­же­не­рия. Ме­то­до­ло­ги­че­ские ос­но­вы. М., 2006; Kruchten P., Ob­bink H., Stafford J. The past, present and future for software architecture // IEEE Software. 2006. Vol. 25. № 2.

Вернуться к началу