Ііі дәріс сабақтарының қысқаша конспектілері 1- 2 дәрістер. Программалау технологиясы. Негізгі түсініктер мен ұстанымдар. Программалау технологиясының даму кезеңдері



Дата04.03.2016
өлшемі444.41 Kb.


ІІІ Дәріс сабақтарының қысқаша конспектілері

1- 2 дәрістер. Программалау технологиясы. Негізгі түсініктер мен ұстанымдар. Программалау технологиясының даму кезеңдері

Программалау технологиясы, бұл- программалық жабдықтарды жасау процесінде қолданылатын қолданылатын арнайы әдістер мен құралдардың жиынтығы.

Электрондық-есептеуіш машиналар алғаш қолданыла бастаған кезеңнен бастап қазіргі уақытқа дейін оларға арналған программалар жазу негізгі мәселелердің бірі болып саналады. Программалық жабдықтың өмірлік циклы деп, оны құру туралы идея пайда болған кезден бастап, оны жасаған фирманың программалық жабдықты әрі қарай қолдап жетілдіруі тоқтатылғанға дейінгі уақытты айтады.

Программаның өмірлік циклының құрылымы ISO IEC 12207: 1995 Information Technologe - Software Life Cycle Processes (Информационные технологии - Процессы жизненного цикла программного обеспечения) халықаралық стандартымен анықталған, мұндағы ISO – International Organization for Standardization (Международная организация по стандартизации) және ІЕС - International Electrotechnical Commission (Международная комиссия по электротехнике).

Аталған стандарт бойынша программалық жабдықты құру келесі процесстерден тұрады:


  • даярлық жұмыстары;

  • болашақ жүйеге немесе программаға қойылатын талаптарды анықтау;

  • болашақ жүйенің немесе программаның архитектурасын жобалау;

  • программаға қойылатын талаптарға талдау (анализ) жасау;

  • программалық жабдықты детальды жобалау;

  • программалық жабдықтың кодын жасау және тестілеу;

  • программалық жабдықты жүйеге кірістіру;

  • программалық жабдықты құжаттау;

  • программалық жабдықты қолдап отыру.

Программалау технологиясының даму кезеңдерінің бастапқысы, стихиялы программалау кезеңі болып табылады. Бұл кезеңде, қазіргі жоғары деңгейдегі программалау тілдері болмағандықтан программалар машиналық тілде жазылды, мысалы, 1958 жылы академик С. А. Лебедевтің басшылығымен жасалған, М-20 есептеулерге арналған электронды есептеуіш машинасы номерленген командалардан тұратын программаны орындай алатын болды (3.1-сурет).




Номер 

Команда 

Операндалар сақталатын жедел жады ұяшықтарының адрестері

0100 

01 

1234 

6543 

3489

0101 

02 

4563 

0567 

3456

0102 

05 

3489 

3456 

2987

3.1-сурет. М-20 ЭЕМ-на арналып жазылған программа мәтіні

Алғашқы кезеңдерден бастап-ақ, программистердің алдындағы міндет, жадыдан аз орын алатын және тез жұмыс жасайтын программа құру әдістерін табу керек болды, мысалы, қазіргі программалау тілдерінде сирек болса да қолданылатын GOTO операторы да соның бір көрінісі болып табылады.

Мұндай тәсілдерді қолдану программаның статикалық түрінің динамикалық түрімен сәйкес келмеуіне әкеліп соқтыратын болғандықтан бұл программаларды программисттер өз тілдерінде BS-программалар (Bowl Spaghetti - блюдо спагетти) деп атайтын болған. Кейбір жағдайларда программисттің өзі құрған BS-программасының қатесін өзі таба алмай қалатын кездері болады ( 3.2-сурет):

3.2-сурет. BS-программа листингісінің фрагменті

Программалық жабдықты құрудағы негізгі міндеттердің бірі программаның статикалық күйі, яғни бастапқы жазылуымен (немесе листингісі) оның динамикалық күйі, яғни компьютердегі орындалу тәртібі сәйкес келуі керек немесе программа командалары жазылу реті бойынша орындалуы тиіс.

Бұл мәселені шешу үшін жаңа тиімді программалау технологиясын жасау қажет болды. Бұл ізденістің нәтижесінде 70- жылдардың басында IBM корпорациясы ұсынған, теориялық негізін профессор Э. Дейкстра қалаған құрылымдық программалау технологиясы пайда болды. Мұнда, программалар белгілі бір ережелерге сәйкес немесе технологиялық әдістерге негізделіп құрылатын болды. Мұның негізінде күрделі программаларды кішкентай шағын программаларға жіктеп алу яғни «декомпозиция» принципі жатыр. Бұл кезеңнің программалары модульдерден құралды. Модульдерден құралған мұндай программалар көптеген мәселелерді шешкенімен, оның тиімсіз жақтары да болды. Мысалы, неғұрлым подпрограммалар көп болған сайын, ол подпрограммаларда программаға қатысатын кең ауқымды (глобалдық) мәліметтердің өзгеріп кетуі көбейеді, сондықтан әрбір подпрограмма өзі орындалып болған ортақ пайдаланылатын кең ауқымды соң мәліметті қайтадан бастапқы қалпына келтіріп қоюы қажет болды. Сондықтан әрбір подпрограмманың ішінде өзінің локальдық мәліметтерін жасау қажеттілігі туындады (3.3-сурет).



3.3-сурет. Құрылымдық программалау элементтері

Мысалы квадрат теңдеуді шешу қажет болса, коэффициенттер ғана негізгі программадан алынады, ал дискриминантты табу ол локальдық айнымалы арқылы жасалады. Құрылымдық программалаудағы тағы бір мәселе, бір программаға қатысты әртүрліподпрограммаларды бірнеше программисттің бір мезгілде параллель құра алу мүмкіндігімен байланысты туындады. Әрине, бұл тәсіл программаны құру уақытын біраз қысқарта алады, бірақ, мұнда стихиялы түрде «төменнен жоғары» қарай программалау қағидасы қолданылды, яғни әуелі қарапайым подпрограммалар жасалып, сонан кейін оларды біріктіріп күрделі программалар жасалатын болды. Ал, бұл подпрограммаларды біріктіріп қалған кезде, ортақ ережелер болмағандықтан негізігі программаны алу өте қиын болды, яғни түрліше стильде жасалған подпрограммаларды біріктіру қиынға соқты. Мұны, ХХ ғасырдың, 60-жылдары «подпрограммалаудағы кризис» деп атады.

Модульдік программалау (3.4- сурет) көп мәселелерді шешті оның тиімсіз жағы, егер программаға бірнеше модуль қатынасатын болса, онда олардың өзара байланысындағы қателер, яғни интерфейстегі қателерді тек программаның орындалуы кезінде ғана байқау мүмкін болатын болды, себебі модульдер программадан тыс өз алдына бөлек компиляцияланады. Егер программаға қатысатын модульдер саны көп болса, мұндай қателердің бәрінің алдын алу мүмкін емес екені белгілі болды.



3.4-сурет. Модульдік – құрылымдық программалау элементтері

Келесі кезеңде, объектілік ұстаным қолданыла бастады. Мұнда программа объектілердің жиынтығынан жасалады. Бұл объектілер белгілі бір класқа жатады. Ал ол кластар белгілі бір иерархияға бағынады, және соңғысы алдынғысының барлық қасиеттерін қабылдайды, және олар өзара «оқиғалар» арқылы байланысады. Бұл кезеңдегі ең алғаш имитациялық модельдеу тілі Simula болды. Қазіргі, Delphi, Visual C++, C++ Builder, Visual Basic, Java бұлардың барлығы да RAD технологияларға жатады және объектілік ұстанымды барынша қолдайды. Бұл технологиялардың тиімсіз тұсы - компиляциялаудағы ортақ стандарттардың болмауы. Мысалы, белгілі бір алгоритмге сәйкес Visual C++ ортасында жазылған программаны, сол алгоритм үшін C++ Builder ортасында пайдалану мүмкін емес, яғни сол алгоритмді қайтадан жазу керек болады, сол сияқты объектілік компоненттің бір сипаттамасы өзгертсе болды, онда соған сәйкес программаны да қайтадан компиляциялаудан өткізу қажет болады.

Жоғарыда аталған мәселені шешуді программалаудағы компоненттік ұстаным (COM- технологияның) көмегімен шешуге болатыны қазір белгілі болып отыр. Компненттік ұстанымның мағынасы, мұнда программалар өзара бір-бірімен стандарт түрдегі екілік интерфейс арқылы байланысады және бинарлық (екілік форматтағы) компоненттерден құралады. Мұндағы объект– компоненттердің кәдімгі объектілерден өзгешелігі оларды динамикалық кітапханаларға немесе exe-файлдарға біріктіріп екілік түрде, бастапқы мәтінсіз (без исходных текстов) тарата беруге болады және оны осы компоненттік технологияны ұстанатын кез-келген тілде пайдалана беруге болады. COM- технологияның қарапайым мысалы, Paint графиктік редакторында жасалған сурет-объектіні Word- мәтіндік редакторындағы құжатқа апарып кіріктіруге болады.


3-4 дәрістер. Программалық жабдықтардың технологиялық сипаттамаларын анықтау

Жалпы «технологиялық тиімділік» деп, программалық жабдықтың жобасының сапасын түсінеді. Программалық жабдықты жасауға және оны кейіннен жетілдіріп отыруға кететін еңбек және материалдық ресурстар тікелей жобамен (проектімен) байланысты болады. Барынша жан-жақты, сауатты құрылған жобаны кодтау, тестілеу, жөндеу және және модификациялау да жеңіл болады.

Программисттердің жинақталған тәжірибелері бойынша программалық жабдықтың технологиялылығы келесі факторлармен анықталады:


  • модельдің жан-жақты қарастырылғандығы (проработанность моделей);

  • модульдердің өзара тәуелсіздігінің деңгейі (уровень независимости модулей);

  • программалау стилі (стиль программирования);

  • кодтарды қайталап қолдану дәрежесі (степень повторного использования кодов).

Програрммалық жабдықтың моделі неғұрлым толық зерттелген, жан-жақты ескеріліп жасалған болса, онда жалпы есепке кіретін бөлек есептерді (подзадачаларды), мәліметтердің құрылымын және т.б. анықтау да соғұрлым нақтырақ болады, оларды жобалау және жүзеге асыру жеңіл болады, қателер азаяды. Ал модульдер неғұрлым өзара тәуелсіз болса, соғұрлым олардың жүзеге асырылуы, модификациялануы, олардағы қатені іздеу және т.б. жеңіл болады.

Программалау стилі деп программаны әрлеу стилін және құрылымдылығын түсінеді. Программаның құрылымдылығы оның оқылуына (читаемость программы) және программалауда қате жіберілмеуіне әсер етеді. ХХ ғасырдың 60-жылдарындағы кризис, яғни спагетти- программалар осы құрылымдылықтың болмауының нәтижесі.

Кодтардың қайта пайдаланылу дәрежесі, бұл бұрыннан бар кітапханаларды, кластарды, подпрограммаларды пайдаланумен және жаңадан жасалған кодтарды унификациялаумен анықталады. Бұл барлық жағдайда тиімді болмауы мүмкін, мысалы кодтарды қайта пайдалану жасанды түрде жоғарылатылса, онда жобаның технологиялылығы да соғұрлым төмендеуі мүмкін.

Программалық жабдықтың жалпы құрылымы анықталғаннан кейін, әдетте ұстаным таңдалынады: құрылымдық ұстаным немесе объектілік ұстаным немесе компоненттік ұстаным .

Ұстаным анықталғаннан кейін, жоғарыдағы айтылған программаның жалпы құрылымын жеке компоненттерге декомпозициялау басталады, бұл декомпозиция мүмкін емес болғанға дейін жүреді. Мұндай декомпозицияның нәтижесі, құрылымдық ұстанымда – подпрограммалар мен модульдердің иерархиясы болып шығады, ал объектілік ұстанымды пайдаланатын декомпозиялауда, класстар түріндегі иерархия алынады.

Модуль (Unit) – жеке автономды түрде компиляцияланатын программаның бірлігі. Модульдердің өзара тәуелсіздігі екі критериймен анықталды: жабысу(сцепление) және байланысу (связность).

Жабысу – бұл модульдердің бір-бірінен неғұрлым алшақтығын анықтайды. Егер бір модульде екінші модуль туралы ешқандай ақпарат берілмесе, онда олар тәуелсіз, ал олар бір-бірі туралы ақпарат сақтайтын болса, онда жабысқан болып есептеледі. Жабысудың келесі түрлері анықталған:


  • мәндер бойынша (по данным);

  • үлгі бойынша (по образцу);

  • басқару бойынша (по управлению);

  • жалпы мәліметтер орналасқан облыс бойынша (по общей областей данных);

  • ішкі компоненттері, мәліметтері бойынша (по содержимому).

Егер «жабысу» жеке-жеке модульдердің бір-біріне алшақтық арақатынасын анықтаса, «байланысу» бір модуль ішіндегі программалық элементтердің өзара байланысу деңгейін анықтайды. Өзара тығыз байланыста болатын элементтерді бір модульге орналастырған тиімді болады, ал егер оларды әртүрлі модульдерге орналастырса модульдердің бір-біріне тәуелділігі артады, бұл қиынырақ болады. Әлсіз байланысқан элементтерді де бір модульде пайдалану оның технологиялылығын төмендетеді. Әзірге байланысудың келесі түрлері анықталған(кему дәрежесіне қарай):

  • функционалды (функциональная);

  • тізбектей (последовательная);

  • ақпараттық (коммуникативная или информационная);

  • процедуралық (процедурная);

  • уақытша (временная);

  • логикалық (логическая);

  • кездейсоқ (случайная).

Программалық жабдықты құруда қолданылатын негізгі екі әдіс:

  • төменнен жоғары қарай жобалау (восходящий метод);

  • жоғарыдан төмен қарай жобалау(нисходящий метод).

«Жоғары қарай жүру» әдісі бұл бірінші пайда болды, мұнда программаның ең төмені элементтері, сонан соң одан жоғары элементтері т.с. сияқты жасалады. Бұл әдістің тиімсіз жағы, кейін біріктірген кезде компоненттер өзара үйлеспей қалады, программа интерфейсі ең соңынан жасалады, яғни оны алдын-ала көрсетіп алу мүмкіндігі жоқ. Бұл әдіс өндірісте қолданылмайды, әдетте оқыту үшін қолданылады.

«Төмен қарай» программалау мұнда программаның бірінші жоғары деңгейдегі компоненттері жобаланады, әрі қарай біртіндеп төменгі деңгейдегі компоненттері жасала береді, мұнда программаның жасалған бөлігін тестілеу үшін әлі жасалмаған төмендегі компоненттерді арнайы модульдермен («заглушка» программа) алмастыра тұрады.

Құрылымдық программалауда, жалпы есептеу процесі үш түрлі ұйымдастырылады: ызықтық, тармақталатын және қайталанатын. Бұл процесстерді жүзеге асыру үшін жоғары деңгейдегі программалау тілдерінде арнаулы басқарушы операторлар (if, while) қолданылады, ал бұрынғы төменгі деңгейдегі тілдерде басқару жолға көшу арқылы беріліп, спагетти- программалар шығатын болды. Сонымен, 1960 жылдардан бастап осы үш конструкцияны «базалық құрылымдар» деп қабылдау келісілген, оның жазылуының бірнеше түрлі нотациялары бар: блок-схема, псевдокод, Flow-формалар, Насси-Шнейдерман диаграммасы және т.б. . Мысалы, базалық құрылымдардың блок-схема түріндегі жазылуы (3.5- сурет) :



сызықтық



тармақталатын

қайталанатын

3.5- сурет. Базалық құрылымдардың блок-схема түріндегі жазылуы


Программада құрылымдық әдісті көрсету үшін жоғарыдағы блок-схемаларды пайдалану өте үлкен болады және күрделі алгоритмдерді беруде оның мағынасын жоғалтып алады, яғни детализациялау деңгейі төмендеп кетеді, сондықтан программа құрылымын көрсету үшін блок-схемадан басқа: псевдокодтар, Flow-формалар және Насси-Шнейдерман диаграммалары қолданылады.

Псевдокод – бұл алгоритмді мәтін түрінде (текстовая нотация) жазып шығу. Псевдокодтарды жазудың бірнеше варианттары кездеседі. Мысалы, бір нұсқасы төмендегі кестеде берілген (3.6-сурет):




Сызықтық

Тармақталған

Қайталанатын

<1- әрекет>

<2- әрекет>

егер шарт

онда

1-әрекет


әйтпесе

2-әрекет


бітті

әзір шарт

цб

қайталанатын әрекет



цс



3.6- сурет. Базалық құрылымдардың псевдокод түріндегі жазылуы
Flow-формалар құрылымдық алгоритмдерді жазуға арналған графикалық нотация. Flow-форманың әрбір символы – бір басқарушы құрылымды білдіретін төртбұрыш түрінде болады (3.7- сурет), мысалы :


сызықтық



тармақталатын

қайталанатын

3.7- сурет. Базалық құрылымдардың Flow-форма түріндегі жазылуы


Насси-Шнейдерман диаграммасы (3.8- сурет) , бұл Flow-формалардың жетілдірілген түрі болып табылады, егер Flow-формада бәрі төртбұрыш түрінде берілсе мұнда тармақталу шарттары үшбұрыш түрінде көрсетіледі, мысалы:

3.8- сурет. Базалық құрылымдардың Насси-Шнейдерман диаграммасы түріндегі жазылуы


Программаны әрлеу стиліне төмендегілер кіреді:

  • программадағы объектілерге, айнымалыларға, функцияларға дұрыс, мағыналы атаулар беру, мысалы Max_Item, Next_Item;

  • модульді дұрыс жазу ережесі: модульдің аты, қысқаша сипаттамасы (не үшін қолданылады), кіріс және шығыс параметрлерінің қысқаша сипаттамасы, оған қатысатын модульдер тізімі алгоритмнің қысқаша сипаттамасы немесе шектеулер;

  • программаның авторы туралы мәліметтер;

  • идентификациялаушы ақпарат (сериялық номер, нұсқа номері және т.б.)

  • модульдің мәтінін әрлеу стилі және т.б.

Жалпы программалауда программаның тиімділігі оның жылдам орындалуымен және жады көлемін аз пайдалануымен анықталады. Кейбір фрагменттердің дұрыс жазылуы, мысалы, көп қайталануы тиіс циклдер программаның орындалу уақытына тікелей әсер етеді. Қазіргі программалау жүйелерінде программалық жабдықтың тиімділігін оптимизациялауды көбінесе компиляторлар орындайды.

Программаның орындалу уақытын азайту үшін қолданылатын тәсілдер де, бұл әсіресе көп қайталанатын циклдарды программалауда кездеседі:



  • цикл параметрлеріне тәуелсіз шамаларды, өрнектерді циклдан шығару, мысалы:

for (int i=0; i<99; i++)

for (int j=0; j<99; j++)

a[320*i+j]=s[k,l].
бұл циклда *(көбейту 320*i) 10000 рет және, s[k,l] элементін шақыру, яғни массивке сұраныс жасау 10000 рет орындалады. Егер осы жазуды келесі түрде жазсақ 320=28 +26 деп алсақ , сонда келесі түрде жазуға болады:

skl=s[k,l]; //массив элементін шақыруды цикл сыртына шығару

for (int j=0; j<99; j++)

{

KomAin=j<<8+s<<6 //320*i көбейтуді жылжытумен алмастыру



for (int i=0; i<99; i++)

a[KomAin+i]=skl;



}…

  • ұзақ «көбейту» амалынан құтылу, ол үшін оларды қосумен, азайтумен, жылжытумен алмастыру;

  • өрнектерде типтерді түрлендіруді азайту;

  • шарттарды тексеруде, артық тексерулер жасамау;

  • массив элементіне индекстері бойынша сұраныс жасамауға тырысу, себебі сол элементтің адресін табу үшін индекстердің мәніне көбейту амалы орындалады, сондықтан жадыдан массив элементтерінің мәнін бір рет оқып алып, оны бір скаляр шамаға меншіктеп, оны керек жерде пайдалана беруге болады.

Программаны компиляциялау және жинау кезіндегі қателерден, яғни синтаксистік қатеден басқа программаның орындалу кезінде пайда болатын қателер болады, әдетте, оларды динамикалық қателер деп атайды. Олардың көрінуі де түрліше болады, мысалы жүйе қате туралы хабарлама береді немесе тұрып қалады, түсініксіз нәтижелер де беруі мүмкін. Сондықтан программалауда кетуі мүмкін қателерді алдын ала ескеріп, оларды уақытында табу және жою үшін арнаулы әдістер қолданылады. Мұның барлығы программалауда «ерекше жағдайларды өңдеу» (обработка исключительных ситуации) деп аталатын мәселеге әкеледі. Ерекше жағдайларды өңдеу механизмі арнаулы аппараттық немесе тілдік құралдар көмегімен қателерді тауып алып, оны өңдеуге мүмкіндік береді, яғни программаның қауіпті жағдайда қалуына жол бермейді.
5- дәріс. Программалық жабдықтарға және оларды жобалаудағы бастапқы мәліметтерге қойылатын талаптарды анықтау
Программалық жабдықтың өмірлік циклының негізгі кезеңдерінің бірі- есептің қойылуы кезеңі. Мұнда программалық жабдықтың орындайтын қызметі және программалық жабдыққа қойылатын талаптар анықталады. Бұл талаптар екіге бөлінеді:

  • функционалдық талаптар, яғни бұл болашақта жасалатын программаның қандай жұмыстарды, функцияларды орындайтынын анықтайды;

  • эксплуатациялық талаптар, бұл болашақ программалық жабдық қандай жағдайларда жұмыс жасайтынын анықтайды.

Программалық жабдықтарға қойылатын негізгі эксплуатациялық талаптарға төмендегілер жатады :

  • дұрыстығы, техникалық тапсырмаға сәйкес жұмыс жасауы ;

  • универсалдығы – кез-келген мүмкін жағдайларда дұрыс жұмыс жасауы ;

  • сенімділігі – түрлі қателерден кейін дұрыс жауаптарды қайтара алуы;

  • тексерілуі - нәтижелерді тексеру мүмкіндігі;

  • нәтиженің дәлдігі - нәтижелер ауытқуының берілген шамадан аспауы;

  • қорғалған болуы - ақпараттың құпиялылығын сақтай алуы;

  • программалармен үйлесімділігі - басқа программалармен үйлесімді жұмыс жасау мүмкіндігі;

  • аппаратпен үйлесімділігі - кейбір құрылғылармен үйлесімді жұмыс жасау мүмкіндігі ;

  • тиімділігі - техникалық ресурстарды аз және жылдам пайдалану мүмкіндігі ;

  • бейімділігі - түрлі жағдайларға байланысты жасалатын модификацияларға бейімділігі;

  • қайта пайдаланыылуы - қайта жүктемей-ақ іске қосыла беруі ;

  • реентерабелділігі – бірнеше процестерде параллель қолданыла беруі.

Техникалық тапсырма- программалық жабдықты құру мақсаттары, оған қойылатын талаптар, жасау уақыты мен кезеңдері, тапсырыс берушіге өткізу мерзімі және т.б. көптеген мәліметтер қамтылған программалық жабдық туралы толық мәлімет беретін құжат. Техникалық тапсырманы жасауға тапсырыс беруші де және оны орындаушы да қатысуы керек. Ол келесі бөлімдерді қамтиды:

  • кіріспе;

  • программалық жабдықтар жасаудың қажеттілігін негіздеу;

  • программалық жабдықтардың қызметі;

  • программалық жабдықтарға қойылатын талаптар;

  • программалық жабдықтардың құжаттарына қойылатын талаптар;

  • техникалық-экономикалық көрсеткіштер ;

  • құру кезеңдерімен стадиялары;

  • программалық жабдықты қабылдау және бақылау тәртібі.


6,7-8 дәрістер. Құрылымдық ұстанымға негізделген программалық жабдықтардың ерекшеліктері
Программалық жабдықтың өмірлік циклындағы маңызды кезеңнің бірі – бұл программалық жабдықтарға қойылатын талаптарға анализ жасау негізінде программалық жабдықтардың ерекшелігін немесе спецификациясын анықтау болып табылады. Спецификация (specify-дәл анықтау- точно определять, spesisication- детальдары- детали, specific- ерекше сипаттамалары- особый отличительный характер) – бұл жасалатын программалық жабдықтардың және оған қойылатын шектеулердің формалды түрдегі дәл сипаттамалары. Сонымен, программалық жабдықтардың спецификациясы, бұл программалық жабдық туралы дәл және толық сипаттама. Спецификация негізгі екі бөлімнен тұрады:

  • функционалдық бөлім, программалық жабдықтардың орындайтын функцияларын сипаттайды;

  • эксплуатациялық бөлім, техникалық құрал-жабдықтарға, ақпараттық қауіпсіздікті сақтауға қойылатын талаптарды анықтайды.

Спецификацияның толықтығы, мұнда болашақ жасалатын программалық жабдықтарға қатысты барлық нәрселер ескерілуі керек, яғни программалық жабдықтарды жасаушы үшін (разработчик) ешқандай кедергі, қосымша мәселе болмауы керек.

Спецификацияның дәлдігі, бұл – спецификация тапсырыс (заказчик) беруші мен оны орындаушы (разработчик) тарапынан бірдей мағынада қабылдануы керек.

Программалық жабдықтардың спецификацияларын көрсету үшін кәдімгі табиғи тілдер жарамайды. Сондықтан дәл спецификацияларды көрсету үшін арнайы формальды модельдер қолданылады.

Спецификацияларды анықтау кезеңіндегі формальды модельдерді екі топқа бөледі: ұстанымдарға (құрылымдық, объектілік) тәуелді және тәуелсіз. Классификациясы төменде 3.9- суретте берілген.

Программалық жабдықтардың спецификациясы жан-жақты көрсету үшін әдетте бірнеше модельді қатар пайдаланады.

3.9- сурет. Спецификацияларды анықтау кезеңіндегі формальды модельдер классификациясы

Құрылымдық ұстанымға негізделген программалық жабдықтарды құруда, талдауда және жобалауда негізінен келесі модельдер элементтері қолданылады:


  • мәліметтер ағынының диаграммасы (DFD – Data Flow Diagrams) бұл ақпарат көзі мен оны қабылдаушының арасындағы әрекетті жүйенің (программалық жабдықтардың) процесі түрінде сипаттайды;

  • «мәнді байланыс» диаграммасы (ERD – Entity – relationship diagrams) жүйенің (программалық жабдықтардың) деректер қорын сипаттайды;

  • күйлер ауысуының диаграммасы (STD –State Transition Diagrams) жүйенің уақытқа байланысты күйінің өзгеріп отыруын сипаттайды;

  • процестердің спецификациясы, оны көрсету үшін әдетте тексттер, псевдокодтар, Flow-формалар , Насси-Шнейдерман диаграммалары қолданылады;

  • терминдер сөздігі – бұл спецификациялы беруде қолданылатын терминдер, қысқартылған сөздерге берілетін түсініктемелер.

Күйлер ауысуының диаграммасы (диаграмма переходов состоянии) – бұл ақырғы автоматтардың графиктік формасы болып табылады. Ақырғы автоматтар (конечные автоматы)- техникалық құрылғының дербес іс-әрекетін (детерминированное поведение) модельдеу үшін қолданылатын математикалық абстракциялық ұғым, автоматтар теориясында анықталған.

Күйлер ауысуының диаграммасының қызметі басқару кезіндегі оның реакцияларын немесе поведениелерін (спецификацияны анықтау кезіндегі) көрсету болып табылады. Мұнда басқарушы сигнал немесе қолданушының командасы болуы мүмкін. Бұл команданы алғаннан кейін, жүйе оған жауап ретінде бір әрекет жасайды, яғни сол күйін сақтап қалады, не болмаса басқа күйге ауысады. Автоматтар теориясына сәйкес, мұнда диаграмма тұрғызу үшін, анықталады: бастапқы күй (терминальное состояние); әсер етуші басқарушы сигнал (немесе көшу шарты); орындалатын әрекет немесе бірнеше варианттар.

Функционалдық диаграммалардың қызметі программалық жабдықтар құрамындағы функциялардың өзара байланысуын, иерархиясын көрсетеді. Функционалдық диаграммалардың функционалдық модельдер деп те атайды. Функционалдық моделдің көп тараған түрінің бірі SADT (Structured Analysis and Design Technigue –технология структурного анализа и проектирования). Оны 1973 жылы Д. Росс ұсынған. Функционалдық диаграммаларды тұрғызу келесі қағидаларға негізделген :


      • әрбір функция бір блок ретінде қарастырылады;

      • әрбір блок үшін бастапқы мәлімет, басқарушы команда, функцияны орындаушы механизм (программалық жабдық немесе техникалық құрылғы) және нәтиже анықталады.

Функционалдық диаграммадағы мәлімет, басқарушы команда, функцияны орындаушы механизм және нәтиже барлығы сызықтар (дугалар) түрінде беріледі, мысалы:

Бұл сызықтар іс жүзінде мәліметтердің жиынтығы, нәтижелердің жиынтығы, немесе басқарушы командалар жиынтығы болып табылады (3.10- сурет), мысалы:



3.10- сурет. Қарапайым функционалдық диаграммны кескіндеу

Блоктар диаграммада байланысу реті бойынша сатылы түрде орналасады. SADT диаграммаларда блоктар байланысуының келесі түрлері бар:


  • кіріс блоктың шығыс дугасы келесі орындалатын блоктың кіріс дугасы болады:





  • басқарушы блоктын шығыс дугасы келесі блоктын басқарушы дугасы болады:



  • кіріс бойынша кері байланыста кейінгі блоктын шығыс дугасы алғашқы блоктың кіріс дугасы болады:




  • басқару бойынша кері байланыста кейінгі блоктың шығыс дугасы алдыңғы блок үшін басқарушы дуга болады:





  • шығыс-орындаушыда алғашқы блоктың шығыс дугасы келесі блоктың орындаушы механизмі болады:


9,10-11 дәрістер. Объектілік ұстанымға негізделген программалық жабдықтардың ерекшеліктері және оларға қойылатын талаптар
Объектіге бағдарланған программалау – бұл программалық жабдықты, қандай да болмасын кластың өкілі болып табылатын, объектілердің жиынтығы түрінде құратын программалау методологиясы.

Объектіге бағдарланған жобалау – бұл құрылатын ақпараттық жүйенің (немесе программалық жабдықтың) барлық статикалық және динамикалық модельдерін объектілі декомпозициялау процесі мен модельдердің логикалық, физикалық тұрғыдан беру тәсілдері негізінде жобалау методологиясы.

Объектіге бағдарланған талдау – бұл жобаланатын жүйеге қойылатын талаптар, пәдік облыстағы анықталған кластар мен объектілер тұрғысынан қарастырылатын методология.

Объектіге бағдарланған ұстанымның концептуалдық негіздеріне объектіге бағдарланған ұстанымның моделі жатады. Объектілік модельдеудің негізгі элементтері: абстаркциялау, инкапсуляция, модульділік және иерархия. Қосымша элементтері: типтелу, паралеллизм және тұрақтылық.

Абстракциялау – бұл қандай да болмасын объектіні, өзге объектілерден ажырататын белгілері, сипаттамалары және т.б. арқылы бөліп алу, жалпы абстракциялау объектінің сыртқы ерекшеліктеріне негізделеді. Объектіге бағдарланған ұстанымда, берілген объектінің дұрыс абстракциялануы, жобалаудың негізгі міндеттерінің бірі болып саналады.

Инкапсуляция – бұл объектінің, өзінің ішкі элементерінің, бір бірінен ажыратылу процесі. Бұл процесс кезінде объектінің ішкі құрылымдары мен оқиғалары бір- бірінен дұрыс ажыратылады. Инкапсуляция объектінің интерфейсін қорғау үшін қолданылады немесе объектілік ұстанымда класстың ресурстарын, тек оның өзінің ғана пайдалануын қолдайды. Абстракциялау мен инкапсуляция бірін бірі толықтырады.

Модульділік – бұл программалық жабдықтың декомпозициялану кезінде өзара байланысқан, бірақ өте әлсіз байланысқан модульдерге бөліну қасиеттері. Инкапсуляция мен модульділік қасиеттері абстракцияларды бір- бірінен ажыратады.

Иерархия – бұл жүйедегі абстракцияланудың бір- біріне бағынышты түрде реттеліп орналасуын тағайындайды. Бұл күрделі жүйедегі класстардың құрылымы (иерархиясы). Мысалы, жай және көп қабылдаушылықты айтуға болады.

Типтелу – бұл абстракцияға байланысты класстарды бір бірінен ажырату үшін қойылатын шектеулер.

Паралеллизм – бұл объектінің актив және пассив түрде болуын көрсетеді.

Тұрақтылық – бұл объектінің өмір сүру уақытын көрсетеді.

Объектіге бағдарланған ұстанымның негізгі түсініктері: объект, класс.

Объект класстың экземпляры тұрғысынан қарастырылады. Объектінің күйі, оқиғасы және жеке қасиеттері болады. Объектіге әсер етуді әдіс деп атайды. Класс қабылдаушылық пен инкапсуляция және полиморфизмді (абстракцияны) қанағаттандыратын құрылымдық жиынтық тип ретінде қабылданған..

Объектіге бағдарланған анализ бен жобалау әдістері модельдеу тілі мен модельдеу процестерінің сипаттамаларынан тұрады.

Модельдеу тілі жобаның сипаттамасын беру үшін қолданылатын нотация. Нотация – бұл модельдерде қолданылатын графиктік объектілердің жиынтығы. Модельдеу тілінің синтаксисі де нотациямен анықталады. Процесс – бұл жобаны құру кезінде жасалатын қадамдардың сипаттамалары.

UML (Unified Modeling Language) – бұл 1980-1990 ж. қолданылып келген, объектіге бағдарланған анализ бен жобалаудың орнына келген әдіс болып табылады. UML алу үшін бірнеше авторлардың әдістерін біріктіруге тура келді: Boosh – авторы Гради Буч; OMT (object modeling technique) – авторы Джеймс Рамбо; OOSE (object oriented SoftWare engineering) – авторы Ивар Якобсон.

UML тілінің негізгі мақсаттары мен мүмкіндіктері:


  • қолданушыға түсінікті болатын визуальды модельді құру;

  • модельдегі базалық концепциялардың кеңейтуге бейім болуы;

  • программалау тілдеріне, құру процессіне тәуелсіз болуы;

  • модельдеу тілінің формальды негізде болуын қамтамасыз етеді;

  • объектілік бағдарланған жабдықтар нарығына стимуляция жасайды;

  • практикалық тәжірибелердің ең жақсысын біріктіру және тарату;

UML-дың пайда болу және даму тарихына сәйкес келесі нұсқалары белгілі (3.11- сурет. Википедия бойынша 2011 жылғы мәлімет):

Нұсқа

Қабылданған уақыты

1.1

ноябрь 1997[1]

1.3

март 2000[2]

1.4

сентябрь 2001[3]

1.4.2.

июль 2004[2]

1.5

март 2003[4]

2.0

июль 2005[5]

2.1

Заңды түрде қабылданбаған [2]

2.1.1

август 2007[6]

2.1.2

ноябрь 2007[7]

2.2

февраль 2009[8]

2.3

май 2010[9]

2.4 beta 2

март 2011[10]

3.11 –сурет. UML-дың нұсқалары туралы деректер

UML 1.4.2 нұсқасы халықаралық ISO/IEC 19501:2005 стандартының негізі болып саналады. UML –де қолданылатын негізгі диаграммаларды келесі топтарға бөліп қарастырады (3.12- сурет. Википедия бойынша 2011 жылғы мәлімет):



Құрылымдық диаграммалар

Structure Diagrams:

(Ағылшын тілінде)

Структурные диаграммы:

(Орыс тілінде)



Кластар диаграммасы

Class diagram

Диаграмма классов

Компоненттер диаграммасы

Component diagram

Диаграмма компонентов

Композит/ құрама құрылымдар:

Кооперация диаграммасы (UML2.0) немесе келісімді үйлестіруші диаграмма

Composite structure diagram:

Collaboration (UML2.0)

Композитной/составной структуры:

Диаграмма кооперации (UML2.0) или диаграмма сотрудничества

Таратылған диаграмма

Deployment diagram

Диаграмма развёртывания

Объектілер диаграммасы

Object diagram

Диаграмма объектов

Пакеттер диаграммасы

Package diagram

Диаграмма пакетов

Профильдер диаграммасы (UML2.2)

Profile diagram (UML2.2)

Диаграмма профилей (UML2.2)

Өзгеру диаграммалары

Behavior Diagrams:

Диаграммы поведения:

Қызмет диаграммасы

Activity diagram

Диаграмма деятельности

Күй ауысу диаграммасы

State Machine diagram

Диаграмма состояний

Прецеденттер диаграммасы

Use case diagram

Диаграмма прецедентов (вар-тов)

Өзара әрекеттесу диаграммасы:

  • Коммуникация диаграммасы (UML2.0) / кооперация диаграммасы (UML1.x)

  • Өзара әрекеттесуді шолу диаграммасы (UML2.0)

  • Реттілік диаграммасы

  • Синхронизация диаграммасы (UML2.0)

Interaction Diagrams:

  • Communication diagram (UML2.0) / Collaboration (UML1.x)

  • Interaction overview diagram (UML2.0)

  • Sequence diagram

  • Timing diagram (UML2.0)

Диаграммы взаимодействия:

  • Диаграмма коммуникации (UML2.0) / Диаграмма кооперации (UML1.x)

  • Диаграмма обзора взаимодействия (UML2.0)

  • Диаграмма последовательности

  • Диаграмма синхронизации (UML2.0)

3.12- сурет. UML –де қолданылатын негізгі диаграммалар

Мысалы, UML 2.3 нұсқасында қолданылатын диаграммалар «құрылымын» UML- дегі «класстар диаграммасын» (class diagram) пайдаланып келесі түрде көрсетуге болады (3.13 - сурет).

Варианттар диаграммасы – бұл ұғымды Ивар Якобсон енгізген. Бұл варианттар диаграммасы жүйенің қандайда болмасын сыртқы әрекетіне жауап беруі. Әдетте, варианттар диаграммасы жүйе мен қолданушы арасындағы қатынасты сипаттайды. Программалық жабдықты жобалауда варианттар диаграммасы қолданушының қандай функцияларды орындау керектігін анықтау үшін жасалады. Мұнда байланыстың екі түрі қолданылады: USES (қолдану), EXTENDS (кеңейту)

CASE құралдар варианттар диаграммасында детализацияны әр түрлі деңгейде қолданады. Мысалы: Якобсон он адам бір жыл жасайтын жобалардағы варианттар саны 20-дан аспау керек деп есептейді.



3.13- сурет. Диаграммалар құрылымы
Класстар диаграммасы – жүйедегі класстардың статикалық құрылымын модельдеу үшін және класстар арасындағы байланысты көрсету үшін жасалады.

Класстар диаграммасы объектіге бағдарланған ұстанымдағы негізгі диаграмма болып табылады. Класстар диаграммасының қызметі: жүйедегі объектілердің типін анықтау және олардың арасындағы байланысты көрсету болып келеді. Байланыстың статикалық екі түрі қолданылады: ассосация және подтиптер (тума типтер).

Бұлардан басқа класстар диаграммасының элементтеріне атрибуттар, операциялар және объектілер арасындағы шектеулер жатады. Класстар диаграммасын жобалаудан бұрын, ол диаграмманың қандай мақсатта қолданылатынын анықтап алу керек.

Класстар диаграммасын жобалаушы үш түрлі мақсатта қолдануы мүмкін:



  • концептуалдық аспект – мұнда класстар даграммасы зерттелетін пәндік облыстағы негізі ұғымдарды анықтайды. Бұл ұғымдар болашақта құрылатын класстарға сәйкес болу керек, бірақ іс жүзінде ол барлық уақытта бірдей орындалмайды. Сондықтан концептуалдық модель болашақ ақпараттық жүйемен әлсіз байланыста болады және ол программалау тіліне тәуелсіз болады;

  • спецификациялық аспект – мұнда құрылатын диаграмма ақпараттық жүйенің (программалық жабдықтың) интерфейсі деңгейінде жасалады. Класстың өзінің ішкі құрылымы қарасытырылмайды;

  • жүзеге асыру аспектісі (реализация) – мұнда класстар диаграммасы ақпараттық жүйеге (программалық жабдыққа) қатысатын класстарды ішкі құрылымдарымен қоса анықтайды. Бұл аспекті программистер үшін негізгі диаграмма болып табылады.


12- дәріс. Қолданушының интерфейсін құру. Қолданушы интерфейстерінің түрлері және оларды құру кезеңдері
Программалау технологиясында, қолданушының компьютердің программалық және аппараттық жабдықтарымен жұмыс жасау үшін пайдаланатын әдістері мен құралдарының жиынтығын «қолданушының интерфейсі» деп атау келісілген.

Қазіргі заманауи ақпараттық жүйелердің жұмыс жасау мүмкіндіктері қолданушының интерфейстерімен тығыз байланысты. Мысалы, қандай да болмасын объектінің (компьютер, программалық жабдық немесе подпрограмма) интерфейсі өзгермейтіндей тұрақты болса, онда объектінің өзін өзгертуге көбірек мүмкіндік болар еді, яғни оның басқа объектілермен (мысалы, қолданушымен) қарым-қатынас қағидалары қарастырылмайды.

Есептеу жүйелеріндегі интерфейстерді компьютерлік техникаға қатынас тұрғысынан келесі топтарға бөледі (3.14- сурет):


  • аппараттық интерфейс;

  • программалық интерфейс;

  • қолданушының интерфейсі.

Есептеу жүйелеріндегі интерфейстер






программалық интерфейстер:



аппараттық интерфейстер:

қолданушының интерфейстері:

Желілік интерфейс

Желілік шлюз

Шиналар


Командалық жол интерфейсі

Графиктік интерфейс

Диалогтық интерфейс

Кәдімгі тілдегі интерфейс

Тактильдік интерфейс

Дыбыстық интерфейс

Нейрокомпьютерлік интерфейс



Функция интерфейсі

Қосымшаны программалау интерфейсі (АРІ)

Процедураларды қашықтан шақыру

СОМ- интерфейс

Объектіге-бағдарланған программалаудағы интерфейс

3.14- сурет. Есептеу жүйелеріндегі интерфейстер


Қолданушының интерфейсі барынша қолданушыға жақын болуы қажет, себебі қолданушының назары программада емес, керісінше өзінің жасап жатқан құжатында болуы керек. Мысалы, жиі қолданылатын командалардың бірі 2-3 деңгейлерде яғни басқа бір ішкі мәзірлерде орналасса , оны іздеуге қолданушының біраз уақыты кетіп отыратын болса, онда интерфейсті қолданушыға жақын немесе ыңғайлы деп айтуға келмейді. Программалық жабдық үшін интерфейстің маңызы өте зор. Программа қанша жерден жақсы бола берсін, егер онымен жұмыс жасау ыңғайсыз болса, онда оны қолданушы қабылдай алмайды.

Қолданушы интерфейстерінің қазіргі көп тарағаны- графиктік интерфейс. Мысалы, Windows операциялық жүйесінің көп таралуының бір себебі, оның қолданушыға ыңғайлы графиктік интерфейсінің болуы деп айтылып жүр. Қолданушының графиктік интерфейсі (Graphical User Interface, GUI) 1970-ші жылдардың ортасында, Xerox Palo Alto Research Center-де (PARC), Smalltalk ортасында жұмыс істейтін Alto және Star машиналары үшін жасалған алғашқы жұмыстардан басталды. Кейде оны «визуальды интерфейс» немесе «терезелі графикалық орта» деп атайды. Қазіргі заманауи жүйелердің көпшілігінде, мысалы,  Microsoft Windows,  Mac OS, Solaris, GNU/Linux, NeXTSTEP, OS/2, BeOS,  Android,  iOS,  Bada, MeeGo жүйелерінде қолданушының графиктік интерфейстері пайдаланылған.

Қолданушының графиктік интерфейсі графиканы растрлық экран дисплейінде қолдануға мүмкіндік береді. Графика экранда элементтердің нақты орнын көрсетеді, ақпаратты берудің визуальды ортасы және көрнекі графика және форматталған мәтіндер барлығы бірігіп «не көрсең соны аласың» (WYSIWYG - What you see is what you get) мүмкіндігін береді.

Қазіргі қолданушылар компьютерді үйрену және жаңа программаларды меңгеру үшін көп уақыт шығындамайды. Windows үшін жазылған программалық жабдықтардың көбінде дерлік бір типтес қолданушы интерфейстері пайдаланылатындықтан, олар қолданушы үшін бір мағынада қабылданады. Windows жүйесі осыған көмектеседі. Windows үшін жазылған программалық жабдықтардың қолданушыға арналған интерфейсінің негізгі элементтері: терезелер, мәзірлер, сұхбат терезелері, суретті батырмалар және т.б. болып табылады.

Қолданушының интерфейсін құру кезеңдері программалық жабдықты құзу кезеңдерімен сәйкес келеді және есептің қойылуы, талаптар мен спецификацияларды анықтау, жобалау, жүзеге асыру, тестілеу мен жөндеу секілді кезеңдерді қамтиды.
13- дәріс. Программалық жабдықтарды тестілеу. Программалық жабдықтардың сапасын тексерудің түрлері
Программалық жабдықтың өмірлік циклының бір кезеңін програмалық жабдықты тестілеу процесі құрайды. Программалық жабдықтарды тестілеу өте көп уақытты қажет ететін күрделі де ұзақ процесс.

Программалық жабдықты тестілеудің мақсаты бұл құрылған программаның бастапқы техникалық тапсырмаға сәйкес толық орындалуын тексеру және оны қолданысқа енгізгенге дейін мүмкін болатын қателерін табу болып есептеледі.

Тестілеу процесі программалық жабдыққа қатысты жасалатын валидация және верификация процесстерінің құрамына кіреді.

Халықаралық ISO 9000:2000 стандарты бойынша, валидация (validation)- программалық жабдықтың қолданушының немесе тапсырыс берушінің нақты талаптарын дәл және толық қанағаттандыратындығын объективті фактілер негізінде дәлелдеу үшін жүргізілетін процесс. Верификация (verification)- программалық жабдықтың сапасына қатысты ішкі ережелер мен стандарттарға спецификациялардың сақталған- сақталмағандығына тексеру үшін жасалады. Мысалы, программалық жабдықты орындауға жіберіп, белгілі бір мәндер үшін шыққан нәтиженің дұрыс-бұрыстығын тексеру валидация процесіне жатады, ал программаны орындауға жібермей-ақ, оның кодын рецензиялау, синтаксистік жазылуларын тексеру және т.б. верификациялау процесіне кіреді.

Қазіргі уақытта программалық жабдықтардың сапасын тексеру үшін жүргізілетін тестілеу процесстерін классификациялау бірнеше категориялар бойынша жасалған.

Программалық жабдықтың өзін тестілеу объектісі ретінде қарастыратын тестілеу процесстеріне келесілер жатады:


  • функционалдық тестілеу (functional testing);

  • өнімділікке тестілеу (performance testing);

  • жүктемелерге тестілеу (load testing);

  • стресс-тесілеу (stress testing);

  • тұрақтылыққа тестілеу (stability / endurance / soak testing);

  • юзабилити-тестілеу (usability testing);

  • қолданушының интерфейсін тестілеу  (UI testing);

  • қауіпсіздікке тестілеу (security testing);

  • локализацияға тестілеу (localization testing);

  • үйлесімділікке тестілеу (compatibility testing).

Тестілеу процесінің автоматтандырылу дәрежесіне байланысты келесі топтарға бөлінеді:

  • қолмен тестілеу (manual testing);

  • автоматтандырылған тестілеу (automated testing) ;

  • жартылай автоматтандырылған тестілеу (semiautomated testing).

Тестілеу процесінде қолданылатын теориялық әдіс- тәсілдерге немесе механизмдерге байланысты төмендегідей түрлері анықталған :

  • «қара жәшік» әдісі бойынша тестілеу (black box);

  • «ақ жәшік» әдісі бойынша тестілеу (white box);

  • «сұры жәшік» (grey box).

Программалық жабдықтың құрамына кіретін компоненттерінің бір- біріне тәуелсіздігін немесе өзара байланыстарын тексеру мақсатында жүргізілетін тестілеу түрлері:

  • компоненттік (модульдік) тестілеу (component/unit testing);

  • интеграциялық тестілеу (integration testing);

  • жүйелік тестілеу (system/end-to-end testing).

Программалық жабдықты уақытқа қатысты алғанда тестілеудің төмендегідей түрлері қолданылады:

  • альфа-тестілеу  (alpha testing)

  • қабылдау кезіндегі тестілеу (smoke testing)

  • жаңа қызметтерге тестілеу (new feature testing)

  • регресстік тестілеу  (regression testing)

  • тапсыру кезіндегі тестілеу (acceptance testing)

  • бета-тестілеу  (beta testing)

Программалық жабдықтардың сапасын көтеру мақсатында жыл өткен сайын тестілеу процестерінің қатары жаңа әдістермен, жабдықтармен толығып келе жатқанын байқауға болады.


14-дәріс. Программалық жабдықтарды жөндеу. Қателердің классификациясы
Программалық жабдықты құру кезіндегі маңызды кезеңдердің бірі – программаны жөндеу кезеңі. Программаны жөндеу (Debugging -отладка) кезінде, программадағы қателер табылып, бөліп алынып жөнделеді.

Программаны жөндеу үшін арнайы жөндеуші- программалар (отладчиктер) қолданылады. Программалау жүйелерінде кіріктірілген жөндеуші- программалар болады. Олар программистке программаны бақылап отыру мүмкіндігін береді, яғни қажет болған кезде тоқтату , қайта жүктеу, қадамдап орындау және т.б. сияқты әрекеттерді орындауды ұйымдастырады.

Программист өзінің құрған қосымшасы орындалған кезде болуы мүмкін қателерді анықтап, ол қателер бола қалған жағдайда программаның қалай жұмыс жасауы керек екенін алдын-ала қамтамасыз етуі тиіс. Жалпы программалау кезінде жіберілетін қателерді келесі топтарға бөледі: синтаксистік қателер, логикалық қателер және динамикалық қателер.

Синтаксистік қателерге программа мәтінін теру кезінде операторлардың қате жазылуы, операторларды айыру белгілерінің қойылмауы, программа соңының көрсетілмеуі және т.б. жатады. Әдеттте синтаксистік қателерді анықтау компилятордың қызметіне жатады, яғни программа синтаксистік қатесі жөнделмейінше компиляциядан өтпейді.

Логикалық қателер, есеп алгоритмінің дұрыс құрылмауынан болады. Логикалық қатесі бар программалар түсініксіз жұмыс жасайды, мысалы, цикл алгоритмінде циклдан шығу шарты дұрыс құрылмаған болса, онда программа ешбір тоқтамастан қайталанып, нәтиже бермей жұмыс жасауы мүмкін, сол сияқты, есептеу алгоритмдерінде көбейтіндінің бастапқы мәнін нольге тең деп алғанда нәтижеде үнемі ноль шығуы мүмкін және т.б. . Мұндай қателерді программаны тестілеу, яғни әртүрлі мәндер үшін орындап көру арқылы табады.

Динамикалық қателер бұл- программаның орындалуы кезінде пайда, болып оның орындалу тәртібінің бұзылуына немесе нәтижесіз тоқтап қалуына әкеліп соқтыратын қателер. Динамикалық қателерді немесе «орындау уақыты кезіндегі қателер» («ошибка времени выполнения», Runtime errors) деп те атайды. Динамикалық қателерге, мысалы, есептеу кезінде бөлшек бөлімінің нольге тең болуы, түбір астында теріс сан кездесіп қалуы, жады ресурстарының жетпей қалуы, программада көрсетілген маршрут бойынша файлдың табылмай қалуы, принтерде қағаздың бітіп қалуы және т.б. көптеген нәрселер жатады. Қосымшалардағы осындай динамикалық қателерге байланысты болатын жағдайларды «ерекше жағдайлар» деп атап, және олармен жұмыс жасау үшін программалау тілдерінде «ерекше жағдайларды өңдеу» түсінігі енгізілген.


15-дәріс. Программалық жабдықтарды құжаттау. Құжаттаудың ортақ жүйесі
Программалық жабдықтарды құжаттау оның өмірлік циклындағы маңызды процесстердің бірі болып есептеледі. Программалық жабдықтың құжаттарына баспа түрінде немесе цифрлық түрде дайындалған программаны құрушыға арналған құжаттар, қолданушыға арналған нұсқаулықтар, анықтамалықтар, диалог түріндегі электрондық нұсқаулықтар және т.б. жатады. Қазіргі уақытта программалық жабдықтың құжаттарын қолданылу саласына қарай келесі топтарға бөліп жүр:

  • архитектуралық – жобалаушы құжаттар, негізінен программаны құрушыларға арналған. Мысалы, архитектура – жобалаушы құжаттарда программисттер деректер құрылымының не себепті класстар түрінде анықталғанын, немесе паттерннің не үшін таңдалғанын, немесе оларды жетілдіру үшін не істеу керек екенін баяндай алады, мұндай мәселелер программалық жабдықтың техникалық құжатына да, қолданушының құжатына да кірмейді;

  • техникалық құжаттар программада қолданылған алгоритмдерді, қолданушының интерфейстерін, программаның кодын анықтайтын техникалық сипаттағы құжаттар болып табылады. Қазіргі уақытта программалық жабдықтың техникалық құжатын жасаудың автоматтандырылған жүйелері (мысалы, DoxygenjavadocNDoc сияқты құжаттандыру генераторлары) қолданылып жүр;

  • қолданушының құжаттары программалық жабдықты кәсіби қызметтерінде пайдаланатын қолданушыларға арналады. Бұл құжатта программалық жабдықты қалай пайдалану қолданушыға түсінікті түрде дәл және толық берілуі тиіс;

  • маркетингтік құжаттар программалық жабдықты нарықта насихаттау үшін жасалады. Мұнда көпшіліктің назарын аударатын реклама түріндегі материалдар, программалық жабдықтың артықшылықтары және т.б деректер қамтылады.

Программалық жабдықтарды құжаттаудың ортақ жүйесін Қазақстан Республикасының деңгейінде және халықаралық деңгейде қабылданған стандарттар құрайды. Программалық жабдықтарды құжаттандыруға байланысты Қазақстан Республикасы деңгейінде СТ РК ИСО/МЭК 6592-2002 – « Ақпараттық технологиялар. Компьютерлік қолданбалы жүйелерді құжаттандыру бойынша нұсқаулық», СТ РК ГОСТ Р ИСО/МЭК ТО 16326-2006 - «Бағдарламалық инженерия. Жобаны басқару кезіндегі  СТ РК 34.019 қолдануға нұсқаулық», СТ РК ГОСТ Р  ИСО/МЭК 15910-2006 (ГОСТ Р ИСО/МЭК 15910-2002, IDT)- « Ақпараттық технологиялар. Бағдарламалық құралдарды қолданушыға құжат дайындау процессі» және т.б. халықаралық деңгейдегі стандарттар қолданылып жүр.


13

Каталог: repository -> repository2013
repository2013 -> жаһандану жағдайында қазақстандық ҚОҒамдағЫ
repository2013 -> Бюллетень (қазан-желтоқсан) Ғылым салаларының аталымы
repository2013 -> ЖҰмыспен қамту саласындағы гендерлік айырмашылық МӘселесі байжолова Раиса Әлиқызы
repository2013 -> О некоторых математических моделях распространения газа в атмосфере
repository2013 -> Л. Н. Гумилев: этногенез теориясы
repository2013 -> Влияние экологической обстановки на заболеваемость населения в регионах казахстана
repository2013 -> Смағамбет Б. Ж. КӘсіпкерлік және руханилық
repository2013 -> Материалдары
repository2013 -> Қазақ тілінің ғылым тілі ретіндегі маңызы мен мәні хақында


Достарыңызбен бөлісу:


©dereksiz.org 2019
әкімшілігінің қараңыз

    Басты бет