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

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

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

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

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

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

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

Алғашқы кезеңдерден бастап-ақ, программистердің алдындағы міндет, жадыдан аз орын алатын және тез жұмыс жасайтын программа құру әдістерін табу керек болды, мысалы, қазіргі программалау тілдерінде сирек болса да қолданылатын 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- мәтіндік редакторындағы құжатқа апарып кіріктіруге болады.

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

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

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

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

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

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

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

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

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

• 
  мәндер бойынша (по данным);
  
• 
  үлгі бойынша (по образцу);
  
• 
  басқару бойынша (по управлению);
  
• 
  жалпы мәліметтер орналасқан облыс бойынша (по общей областей данных);
  
• 
  ішкі компоненттері, мәліметтері бойынша (по содержимому).
  

• 
  функционалды (функциональная);
  
• 
  тізбектей (последовательная);
  
• 
  ақпараттық (коммуникативная или информационная);
  
• 
  процедуралық (процедурная);
  
• 
  уақытша (временная);
  
• 
  логикалық (логическая);
  
• 
  кездейсоқ (случайная).
  

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

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

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

сызықтық

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

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

Сызықтық	Тармақталған	Қайталанатын
<1- әрекет> <2- әрекет>	егер шарт онда 1-әрекет әйтпесе 2-әрекет бітті	әзір шарт цб қайталанатын әрекет цс

сызықтық

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

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

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

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

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

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

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

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

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

{

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

a[KomAin+i]=skl;

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

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

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

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

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

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

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

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

Спецификацияларды анықтау кезеңіндегі формальды модельдерді екі топқа бөледі: ұстанымдарға (құрылымдық, объектілік) тәуелді және тәуелсіз. Классификациясы төменде 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 диаграммаларда блоктар байланысуының келесі түрлері бар:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 
  қолданушыға түсінікті болатын визуальды модельді құру;
  
• 
  модельдегі базалық концепциялардың кеңейтуге бейім болуы;
  
• 
  программалау тілдеріне, құру процессіне тәуелсіз болуы;
  
• 
  модельдеу тілінің формальды негізде болуын қамтамасыз етеді;
  
• 
  объектілік бағдарланған жабдықтар нарығына стимуляция жасайды;
  
• 
  практикалық тәжірибелердің ең жақсысын біріктіру және тарату;
  

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Желілік шлюз

Шиналар

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

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

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

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

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

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



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

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

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

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

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

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

Қолданушы интерфейстерінің қазіргі көп тарағаны- графиктік интерфейс. Мысалы, 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)
  

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

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

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

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

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

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

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