Коммерциялық емес акционерлік
қоғам
АЛМАТЫ
ЭНЕРГЕТИКА ЖӘНЕ БАЙЛАНЫС УНИВЕРСИТЕТІ
Компьютерлік технологиялар кафедрасы
Программаны
әзірлеудің құрал-жабдықтары
5В070400 – Есептеу техникасы және бағдарламалық қамтамасыз ету
мамандығының студенттері үшін дәрістер конспектісі
Алматы 2013
ҚҰРАСТЫРУШЫЛАР: Конуспаева А. Т. Программаны әзірлеудің құрал-жабдықтары. 5В070400 – Есептеу техникасы және бағдарламалық қамтамасыз ету мамандығының студенттері үшін дәрістер конспектісі.– Алматы: АЭжБУ, 2013. – 55 б.
Дәрістер конспектісі бағдарламалаудың тәжірибелік сұрақтарын қарастырып оқып жүрген 5В070400 – Есептеу техникасы және бағдарламалық қамтамасыз ету мамандығының студенттеріне арналған.
Суреттер - 5, кестелер – 4, әдебиеттер тізімі – 13 атау.
Пікір беруші: доцент Калиева С.А.
“Алматы энергетика және байланыс университеті” коммерциялық емес акционерлік қоғамының 2012 жылғы баспа жоспары бойынша басылады.
© “Алматы энергетика және байланыс университеті” КЕАҚ, 2013 ж.
1 дәріс. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС даму тарихы
Дәріс мақсаты: түсініктемелерді анықтау: программа, программалау деңгейлері және категориялары (бағыттары), программаны өңдеу және аспаптары туралы мағлұматтар беру.
Кіріспе. Аспаптар - ол жұмысты орындау үшін арналған құралдар, яғни программаны өңдеу және тарату екі топқа бөлінеді: аппараттық және программалық. Аппараттық – микропроцессорлар және қосылатын (сыртқы) құрылғылар. Программалық – олар жобалау әдістемелігімен анықталған, барлық жұмыстарды орындауға мүмкіндік беретін программалар. Беріліп отырған пән негізінен, компьютерге программаларды орнату және өңдеу үшін қолданылатын программалық аспаптық құралдарды оқып үйренуге арналған.
Программалық өнімді (ПӨ) өңдеу көптеген бір-бірімен байланысқан әрекеттерден тұрады, олар:
- деректер моделін құру және есептеу әдістемесі;
- есептеуді қамтамасыздандыратын, функционалдық сипаттамасы;
- деректер құрылымын анықтау – компьютерде және алгоритмде көрсетілу моделі;
- есепті тарату әдістерін сипаттау және анықтау (тестер және шешу алгоритмі);
- пайдаланушы интерфейсін сипаттау және анықтау;
- ПӨ қолдау құралдарын анықтау;
- есеп спецификациясы;
- тестілеу программасын қоса отырып, программа мәтінін жазу;
- программаның тестіленуі, трансляциясы және жөнделуі;
- қолдау кітапханаларын қосу және байланыстыру;
- орындау ортасын құру; орындамалық модульді орналастыру және жүктеу;
- орнатылған көмекті құру және өңдеуді құжаттау;
- орнатылатын (инсталляциялық) ПӨ пакетін құру.
Rational Unified Process (RUP) аймағында программаларды өңдеуге арналған әрекеттер жиыны келесі кезеңдерден тұрады: - талаптарды анықтау; - жобалау; - программалау; - тестілеу; -ендіру.
Көрсетілген жұмыстарды орындау үшін көптеген программалар жиынтығы үнемі өңделіп және толықтырылып отырады – ол аспаптар, программаның өңделу процесін автоматтандыру және қалыптастыру үшін мүмкіндік береді. Бұл құралдарды қолдану өңдеу және программалық өнімді енгізу уақытын азайтады.
Компьютер үшін программа – бұл программалау тілінде құрылған немесе жазылған, тәртіптер тізімі. Программалау тілі берілген есепті шешу үшін және тиімді, жылдам, сапалы, үнемді жобалау мақсатында таңдалады.
Тіл деңгейі – программалау деңгейі.
Төменгі деңгейлі программалау – бұл микропроцессор деректер форматын және командаларын кодтық немесе мнемоникалық формада (ассемблер) қолданатын программалау. Проблемалы-бағытталған программалау – бұл деректер форматын және командаларын проблемалы- бағытталған тілдерде программалау. Визуалды программалау – бұл деректер форматын және командаларын программаларды өңдеудің визуалды құралдары арқылы программалау. Объектілік немесе компоненттік программалау әртүрлі конструктивтерді бірлік элемент ретінде қолдануға мүмкіндік береді.
Командалық (атомарлы), құрылымдық, модульдік программалау – категориялары, программаларды өңдеу кезінде қолданылатын тілдің типтік конструкциясымен анықталады. Құрылатын программа үшін, проблемалы аймақ, программалаудың бағытын анықтайды – ғылыми түрде, бизнес есептерін шешу үшін, объектілер мен процесстерді басқару үшін, ақпараттарды көрсету және басқару үшін, Интернет пен қарым-қатынас жасау үшін, деректер қорымен қарым-қатынас жасау үшін және т.б. қолданылады.
Құрылымдық программалау концепциясы.
«Құрылымдық программалау – программалау әдістемелігі, жүйелік түрдегі талдауға негізделген, ПҚ тарату және жобалау. 70-жылдардың басында пайда болды және соншалықты өміршең, сондықтан да осы күнге дейін пайдаланылады. Бұл технологияның негізі келесі тәртіптерден тұрады:
1) Қиын есептер кішірек бөліктерге бөлінеді, функционалды түрде негізінен басқарылатын есептер дұрыс. Әрбір есептің бір кірісі және бір шығысы болады. Бұл жағдайда программа ағымы көптеген есептер тобынан және түсінікті функционалдық тағайындамасынан құралады.
2) Есепте қолданылатын, басқарылатын құрылымның қарапайымдылығы және атомарлығы. Бұл, логикалық есеп минималды, функционалды толық қалыптасқан қарапайым басқарылатын құрылымнан тұруы керек екендігін көрсетеді.
3) Программаның өңделуі кезең бойынша орындалады. Әрбір кезеңде шектелген есеп саны, нақты қойылған тапсырмасымен және есеп барысындағы оның атқаратын мәнімен, түсінікті қойылымы шешілуі керек. Егер ондай шамаға жетпесе, онда ол бұл кезең өте үлкен және оны тағы басқа қадамдарға бөлу керек екендігін білдіреді.
Модулдік программалау концепциясы.
Құрылымдық технология сияқты мұнда да, модульдік программалау концепциясын бірнеше түсініктемелер және тәртіптер түрінде қалыптастыруға болады:
1) Есептің функционалдық декомпозициясы – үлкен есепті кіші есептерге бөлу, олар функционалды өз бетінше орындалатын ішкі есептер - модульдер. Модульдер өзара кіріс және шығыс деректерімен байланысқан.
2) Модуль - модульдік программалау концепциясының негізі. Әрбір модульдің функционалдық декомпозициясы бір кірісі және бір шығысы бар "қара жәшік" ретінде қаралады. Модульдік көзқарас программаның модернизациясын процестің эксплуатациясы кезінде ешбір қатерсіз орындауға мүмкіндік береді және оны қолдап отырады. Қосымша модулдік программалау бір жобаның программасының әртүрлі бөліктерін әртүрлі программалау тілдерінде орындауға мүмкіндік береді, одан кейін жинау құралдары арқылы оларды бір жүктемелеу модуліне біріктіреді.
3) Таратылатын шешімдер қарапайым және түсінікті болуы керек. Егер модульдің атқаратын қызметі түсініксіз болса, онда бастапқы немесе аралық декомпозиция есептері дұрыс, керек еткен деңгейде, сапалы жүрмегендігін білдіреді. Бұл жағдайда есепті қайта талдау керек, мүмкін, қайта бөлулер жасау, яғни ішкі есептерге бөлу жұмыстарын орындау керек болады. Жобада қиын орындалатын орындар кездессе, онда оларды жүйемен ойластырылған түсініктемелер арқылы құжаттау керек. Бұл процесс модульдердің жұмысының толық түсінікті, қызметтері анықталған және байланыстырылғанға дейін қайталана береді.
4) Модульдің барлық айнымалыларының қызметі түсініктеме көмегімен анықталуы және жазылуы керек.
Объектіге бағытталған парадигма.
ОБП идеясы негізінен осы деректерді өңдейтін процедураларды бір бүтін - объектіге байланыстыру үшін жасалған. ОБП маңызды үш принцип негізінде құрылған, олар объектілерге жаңа қасиеттер береді. Бұл принциптер ретінде инкапсуляция, мұрагерлену және полиморфизм алынады.
Инкапсуляция – осы деректерді өңдеу алгоритмдері мен деректерді бір бүтінге біріктіру. ОБП деректері көлемінде – объект өрісі, алгоритмдері – объектілік әдістер алынады. Өрістермен алгоритмдер іштен қолданылады, - жалпы, сырттан немесе тек объект ішінде – соған тәуелді, ішкілер немесе байланысқан объектілер – қорғалған.
Мұрагерлену – объектілер қасиеті өздерінің мұрагерлерін туындайды және оларға өздерінің қасиеттерін үнсіздікпен ұсынады. Объект - мұрагерленуші, ол қасиеттерді толықтыра алады немесе басқамен оны ауыстыра (орынбастыра) алады.
Полиморфизм – туыстық объектілердің қасиеттері (яғни бір объектіден тараған бір түбірі бар объектілер) негізінен бір-біріне ұқсас, мәні жағынан бірдей проблемаларды әртүрлі әдістермен, оның уақытына және орналасу ретіне байланысты шешу.
Программаны өңдеу үшін алынған аспап таңдалған деңгей негізімен, бағытымен, өңдеу категориясымен анықталады және мәтінді немесе визуалды түрде беріледі. Қазіргі заманғы программалау – компоненттік (объектілік), уақиғалық және визуалды болып алынады.
Программаны өңдеу мемлекеттік және шетелдік стандартқа сәйкес, өңдеуші ұсынған технологиялар мен әдістемелер немесе типтік программалар арқылы орындалады.
Аспаптық құралдардың жіктелімі.
Аспаптық құралдардың жіктелімі өңдеу процесі және таратылуының орны бойынша, уақытша принципі бойынша, қолданылатын технологиялары мен әдістемесі бойынша, өнім сапасы бойынша және т.б. жүргізіледі.
Программаны өңдеу процедурасындағы аспаптық құралдардың орны мен атқаратын қызметі.
Әрбір программаны өңдеу кезеңінің өз аспаптар жиыны бар. Әрбір қадам өңдеу нәтижесімен анықталады – негізгі құжат, және қосымша құжат болып, кезеңді жабу алынады. Аспап, сәйкесінше, негізгі немесе қосымша болады.
Сапа мінездемесі және аспапты қолдану.
Жазықтықтағы, уақытша, тұрақты, берік, қазіргі заманғы, интуитивті түсініктер, визуалды, статикалық және динамикалық, өңдеуді түзету және өзгертуді қамтамасыздандыру, нәтижеге байланысты, сәйкес стандарттар мен технологиялар, мақсатын орындалуымен және т.б. болып бөлінеді.
Аспаптық құралдардың дамуына қысқаша түсініктеме.
Кезеңдер 1960 – 1975 – 1985 – 2000 жылдар болып табылады. Тілдер, компиляторлар, компоновщиктер, құрастырушылар, жүктемелегіштер, операциялық жүйелер, өңдеу құралдары және тестілеу, енгізу құралдары және программаны қолдау қамтамасыздандыру туралы түсініктер кіреді.
2 дәріс. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын анықтау. RUP
Дәріс мақсаты: жобалау әдістер және программаның өмір циклын қамтамасыздандыру мәселелерін қарастыру.
Rational Unified Process «Бүгінгі күнде ол ең көп кездесетін әдістемелердің бірі. Ол Rational Software копаниясымен өз өнімдерін қолдау үшін шығарылған, олар оннан көп деп есептелінеді (ең көп кездесетін өнімдеріне - Rational Rose және Requisite Proжатады). RUP үш атақты адамдармен құрылған - бұлар Гради Буч, Ивар Якобсон және Джеймс Рамбо (Rumbaugh). Олардың барлығы қиын программалық қамтаманы өндеуде үлкен жетістіктерге жеткен адамдар, оны RUP бейнесінен – ақ көруге болады. RUP Итеративтігі, қазіргі заманғы дамыған кез келген процесс сияқты, ол да итеративті болып табылады. Бұл яғни, құрылатын жоба бірнеше итерациямен орындалатындығын көрсетеді. Әрбір итерация аяғында жұмыс жасайтын өнім версиясын алуға мүмкіндіктер бар, бірақ олардың функционалдығы толық емес. Одан кейін орындалатын итерацияларда функционалдылық толықтырылып отырады да, соңында дайын өнім ала аламыз.
Итеративті өңдеудің артықшылықтары көп. Релиздердің көп бөлігі өнім сапасына ықпалын тигізеді, олар әрбір итерация сайын тестіленіп отырады. Яғни бастапқы тексерулер жүргізілгеннен кейін-ақ пайдаланушы күткен өнімді алуға мүмкіндіктер бар және өзгертулерді сол кезде енгізуге болады, егер ол қажет болса. Сонымен қатар, жобаны жоспарлау да оңай, өйткені бірінші итерациядан кейінақ ол түсінікті болады және жобаны басқарушы келесі итерацияның аяқталу уақытын да алдын ала жоспарлауға мүмкіндігі болады. Айта кететін жағдай, RUP-та процестің итеративтілігін қатесіз жасауға болатындығы айтылмаған. Сондықтан RUP-ты бірінен кейін бірі орындалатын процесс үшін де қолдануға болады, яғни ондағы орындалу қадамдары бірінен кейін бірі орындалады және дайын өнім соңында алынады. Сондықтан RUP орнатқанда оның итеративтігіне және қатесіз орындалуына көңіл бөліп дұрыс ендіру керек. Пайдаланушы сценарийі. Пайдаланушы сценарийі (Use Case) – бұл белгілі бір операцияны орындау кезіндегі пайдаланушының әрекеттер тізбегінің сипаттамасы. Мысалы, жаңа құжат ашу үшін пайдаланушы сценарийін жазуға болады және т.б. RUP пайдаланушы сценарийлерімен басқарылады (немесе прецеденттер). Пайдаланушы сценарийлері өңдеушілерге жүйе не жасауы және қалай жасауы керек екаедігін нақты айтып отыру мүмкіндік береді. Пайдаланушы сценарийлері жүйенің функционалдық спецификациясының бөлігі болып табылады. Негізінен мұндай сценарийлер программаны өңдеу кезінде тигізетін пайдасы көп, өйткені олар:
- тапсырыс берушіге және жалпыға түсінікті тіл болып табылады да тапсырыс беруші мен өңдеуші екеуін байланыстырушы бөлім болып табылады;
- программа жұмысының логикасындағы қателерді бастапқы жұмыс барысында табуға көмектеседі;
- тапсырыс берушінің программаға деген талаптарын нақты табуға көмектеседі;
- текстілік сценарийлерді жазу үшін интерфейс өңдеушінің базасы болып табылады.
RUP-тағы пайдланушы сценарийлеріне ерекше орын берілген, ол процесс use-case driven деп аталады, яғни пайдланушының басқарушы сценарийлері. RUP құрылымы Процесстің төрт фазасы бар:
1) Зерттеу (Inception).
2) Жоспарды нақтылау (Elaboration).
3) Құру (Construction).
4) Ашып қарау (Transition).
Әрбір фазадағы негізгі көңіл әртүрлі процесстерге бөлінеді. Зерттеу фазасында талаптарды жинау және талдау жүргізіледі, Жоспарды нақтылау фазасында – жүйені жобалау және талаптарды талдау, құру фазасында - өңдеу және кодтау, ашып қарау фазасында – тестілеу және тарату. RUP әдістемесі негізгі 9 ағынға негізделіп жасалады:
1) Бизнес-талдау (керектіктің талдануы).
2) Талаптарды жинау және талаптарды басқару (талаптарды функционалдық спецификацияға ауыстыру).
3) Талдау және модельдеу (талаптарды программалық модельге ауыстыру).
4) Кодтау,
5) Тестілеу (программаның берілген талаптарға сәйкестігін тексеру).
6) Өзгертулерді және конфигурациясын басқару (өнімнің әртүрлі версияларындағы өзгерулерін тексеру).
7) Жобаны басқару.
8) Өңдеу ортасын ұстану және құру.
9) Ашып қарау (өнімді беру немесе сату үшін керектінің барлығы).
RUP – тағы кез келген өнім төрт фазадан өтеді. Осы фазалар арқылы барлық тоғыз ағын да өтеді. Әрбір фаза, өз кезегінде, итерацияларға бөлінеді. Егер, мысалға алатын болсақ, "Зерттеу" фазасындағы бірініші итерация болса, онда бұл итерациядағы негізгі көңіл бизнес-талдауға, талаптарды жинау мен модельдеуге, және кодтауға бөлінеді. Егер "Құру" фазасындағы соңғы бір итерациялардың бірін алатын болсақ, онда негізгі көңіл кодтауға, тестілеуге және конфигурацияны басқаруға бөлінеді. Басқаша айтсақ, жобаның дамуына байланысты әрбір итерациядағы кемшіліктер жойылады. Бұл әрине дұрыс, соңына қарай талдау мүлде керек болмайды, ал талаптарды жинауға кеш болады. Артефакт (Artefact) деп өнімді атаймыз, ол ПҚ өңдеу процессі кезіндеқұрылады және қолданылады. Мысалы, артефакт болып құжаттар, моделдер, орындалатын кодтар алынады. Артефакт мысалдары: пайдаланушы құралы, UML-дағы класстар диаграммасы және т.б. RUP-тың бөлінбейтін бөлігін артефакттар мен олардың атқаратын қызметтері толықтырады. Программаны өңдеу кезінде әртүрлі артефакттар құрылады, сол немесе басқа артефакттардың құрылуына оның атқаратын қызметтері жауапты болады. Мысалы, класстар диаграммасын "Архитектор" құрады, ал сценарилеін және тестіленуін "Тест дизайнерлері" жазады. Барлық визуальды модельдеу CASE-құралдарының көмегімен жүзеге асады. Оның негізін UML тілі құрады (Unified Modeling Language), ол таңқаларлық жағдай емес, өйткені UML RUP авторларымен ойлап табылған дүние.
Ең жақсы практикалар RUP-тың өзі ең жақсы алты практикаға негізделген (best practices):
- Итеративтік өңдеу.
- Талаптарды басқару.
- Модульдік архитектураны қолдану.
- Визуальды модельдеу.
- Сапасын тексеру.
- Өзгертулерді бақылау.
Олар RUP-тың бөлінбейтін бөлігі болып табылмайды, бірақ оларды процессті құру кезінде ұстанған дұрыс деп есептелінеді.
Итеративтік өңдеу бастапқы стадияларда жұмыс жасайтын дайын өнім версиясын алуға мүмкіндік береді және қателерін табуға болады, сонымен қатар, нәтижесінде алынған өнімнің сапасы да жақсы болады, өйткені база өнімде қанша итерация болса сонша рет тестіленеді.
Талаптарды басқару – ол қиын немесе қиын емес өнімдерді алу кезіндегі маңызды бір процесстердің бірі. Бұған байланысты өнім, тапсырыс берушінің талаптарына сәйкестендіріледі. Аспаптық қастамасыздандыру Requisite Pro – ның көмегімен шешіледі.
Теория жүзінде модульдік құрылым кодты қайта қолдануға болады, және жүйе иілгіш болады деп айтылған. Ал практика жүзінде мұны тарату мүмкін емес.
Визуальдық модельдеу жүйенің өсетін қиындықтарымен тиімді күресуге мүмкіндік береді. Моделдер негізінен, жүйенің не істейтіндігін және қалай істейтіндігін түсіну үшін пайдаланылады. Сонымен қатар, модельдер өңдеушілердің арасындағы коммуникация құралы болып табылады, бірақ ол үшін ол барлығына да түсінікті болу керек. Міне осы үшін RUP-та UML қолданылады, ол өңдеушілерге бір тілде сөйлеуге мүмкіндік береді. Аспаптық қолдау Rational Rose-пен қамтамасыздандырылады.
Өнім сапасы – бұл да оның маңызды мініздемесінің бірі. Айтылғандай, RUP – мүмкіндігінше сапа дейгейіне бағытталға, бірақ адаптация процесінде, егер адаптация сәтті болмаса, онда бұл сапамен байланысты әдістемеде қиындықтар тууы мүмкін. Аспаптық ұстанымдар бірнеше программалармен қамтамасыздандырылуы мүмкін, олар: Rational Purify, Rational PureCoverage, Rational Quantify, Rational Robot.
Өзгерулерді бақылап отыру тапсырыс берушінің талаптарының өзгерулеріне және сыртқы құрылғы өзгерістеріне тез жауап беруге мүмкіндік береді. RUP-тың процесстері болады, олар өзгерулерді тиімді бақылауға мүмкіндік береді. Аспаптық ұстанымдар келесі программалармен қамтамасыздандырылуы мүмкін, олар: Rational ClearCase және Rational ClearQuest.
RUP қалыптастыру. RUP адаптацияланатын процесс болып табылады, яғни оларды керекті бір команданың немесе керекті бір жобаның пайдалануына байланысты құрауға болады. Сонымен қатар, мұны жасау керек те, өйткені мұнсыз RUP-ты пайдалану тиімділігі нөлге талпынады. RUP 2000-да, мысалы, 30-дан астам ролдер және 50-ден астам артефактар бар. Шындығында, егер команда 5 адамнан тұрса, онда ондағы барлық ролдерді шығару және барлық артефакттарды құру мүмкін емес. Негізі команда неғұрлым аз болса, соғұрлым процесс жеңіл болады. Яғни минимум артефакттар құрып, минимум рөлдерді енгізу керек.
Сонымен RUP процессті қалыптастыруға мүмкіндік береді. RUP-тың жалпы сипаттамасынан сапалы өнім шығару үшін және бюджет аймағында болатын, командада қолданылатын керек процесстер, рөлдер және артефакттарды алу керек. Мысалы, талаптарды басқаруды алатын болсақ. RUP-тың жалпы сипаттамасында келесі артефакттар бар: талаптарды басқару жоспары, пайдаланушы сценарилерінің моделі, жүйенің талаптарының спецификациясы, көріністер, талаптар репозиториі. Кішкентай жоба үшін талаптар спецификациясы да және жеке сценарилер де жеткілікті. Ал үлкен жоба үшін репозиторий міндетті түрде қажет, өйткені онсыз талаптарды өзгертулер мен оларды бақылау жүйелік аналитиктің жұмысын қиындатады. Бірақ RUP-ты бір нақты жоба үшін қалыптастыру – нетривиальды есеп. Егер ол жұмысты бұрын RUP енгізумен жұмыс жасамаған адам жасаса, онда орындалатын есепті алу мүмкін емес. Негізі, RUP өте қиын әдістеме деп есептелінеді, оны негізінен үлкен командалар үшін қолданған жақсы. RUP-тың жұмысын жеңілдететін бір әдістемелердің бірі бұл dX. Rational Unified Process (RUP) әдістемесі келесі процесстерден тұрады (Workflows):
- бизнес-модельдеу;
- талаптарды басқару;
- талдау және жобалау;
- тарату;
- тестілеу;
- ашып қарау;
- конфигурация және өзгерулерді басқару;
- жобаны басқару;
- аспаптық қолдау.
RUP — итерациондық әдістемесі. Итерациондық әдіс есепті дұрыс түсіну үшін пайдалы, ол есептегі әрбір итерациялар арқылы біртіндеп қателерді табу және оларды жоюды орындауға мүмкіндік береді. Итерацияларды талаптарды дұрыс орындаған кезде және өзгертулерді бақылаған кезде ғана ұйымдастыруға болады. RUP модельді өңдеу және қолдауға негізделген, ал қағаз құжаттар құру үшін ол керек жоқ.
Таңдалып алынған құрылым программалық компоненттердің өңделуін жоспарлау үшін қолданылады. Өнімді өңдеу негізінен жүйемен қолданылатын сценарилерді анықтаудан басталады (Use cases). Сценарийлер процесстің барлық өміршеңдік циклын бағыттайды (бизнес-модельдеу, талаптарды таңдау, талдау және жобалау, тестілеу) және жүйені ашып қарау кезінде есептің орындалуын қамтамасыздандырады.
RUP объекттілі-бағытталған технологияны қолдайды. Көптеген визуальды моделдер және объекттілі-бағытталған модель болып табылады, олар объект концепциясына, класстарға және олардың арасындағы байланыстарға негізделеді. Бұл кездеге жалпы тіл ретінде Unified Modeling Language (UML) алынады.
RUP жүйенің компоненттік өңделуін қамтамасыздандырады. Компонент деп тривиальды емес модульдер саналады. RUP жобада құрылатын барлық материалдардың сапансын бақылауға бағытталған, құрылатын жүйенің сапасына жауапты болып табылады. Сапаны бақылау бағасы процесстің әдістемесінде берілген.
RUP негізінен қиын ақпараттық жүйелерді (АЖ) құру үшін қолданылады, өндіріс масштабын және аспаптық құралдарды Rational Software қолдайды, ол жобамен жұмыс кезіндеге командалық жұмысты қамтамасыздандырады.
Программалық өнімді өңдеу кезінде қолданылатын мемлекеттік және шетелдік стандарттар. Өңдеу сапасын анықтайтын ӨАҚ стандарты. ИСО 4001-96. Сапа жүйесі. Жобалаудағы сапаны қамтамасыздандыру моделі. ӨАҚ МЭК 9126-93. АТ. Программалық Өнімнің бағасы. Сапа мінездемесі және оны басқарудағы қолдану құралдары. ӨАҚ МЭК 8402-94. Сапаны басқару және сапамен қамтамасыздандыру. Сөздік. 34.601-90, 34.603-92, ӨАҚ 4001-96 стандарттары және т.б.
3 дәріс. Талаптарды өңдеу. Логикалық жобалау аспаптары мен әдістері
Дәріс мақсаты: жобалаудың логикалық фазасы мен әдістерін қарастыру.
Командалық және жеке жобалау және оған керекті аспаптар. Мәтінді және визуалды жобалау – технологиялары және әдістемесі, қолданатын аспаптары. Визуалды модельдеу дегеніміз не? Визуалды модельдеу (vіsual modelіng) – нақты өмірдің объектілері мен ұғымдарын көрсететін және өзі көрініс табатын абстракциялардың көмегімен проблемаларды қабылдау әдісі. Модельдеу проблемаларын талдау, барлық қызығушылығы бар жақтар арасында ақпараттардың алмасуы (қолданушылар, пәндік аумақтағы мамандар, аналитиктер, дизайнерлер және т.б.), программалық қолданбалар мен мәліметтер базасын жобалау, және документацияны дайындау үшін пайдалы құрал болып табылады. Модельдеу талаптарын жақсы қабылдауға, жүйенің дизайн сапасын жақсартуға және оны басқару деңгейін жоғарылатуға өз септігін тигізеді. UML – объекті бағдарланған жүйелермен құрастырылатын мәндердің құжаттамасын белгілеу мен көріністендіру үшін қолданылатын тіл.
Модельдің көмегімен біз керегі жоқ детальдарды қарастырмай-ақ бар назарымызды негізгіге аудара отырып, проблеманы оңайлатуымыз мүмкін. Абстракциялау мүмкіндігі – күрделік феноменін шешуге көмектесетін, адам интеллектісінің іргелі қасиеті. Мыңдаған жылдар барысында суретшілер, қол өнершілер және құрылысшылар нақты шығармашылық ойларды жүзеге асыру алдында түрлі модельдерді жобалау талпыныстарын жасаған. Бұл құбылыстар программалық қамтаманы жасау индустриясын айналып өткен жоқ. Күрделі программалық жүйені құрастыру үшін, автор оның қасиеттерін түрлі көзқарастар тарапынан абстракциялауға, белгілеулердің нақты жүйелерінің көмегімен модельдерді жобалауға, олардың бастапқы талаптарға сәйкестігін тексеріп алуға міндетті, тек содан кейін ғана жүйені жаңа функциялармен толықтыра отырып, модельді практикада жүзеге асыруға болады.
12207 стандарты – Программалық жүйенің өміршеңдік циклының процесстері (ПЖ ӨЦ). Есептерді, жұмыстарды, процесстерді анықтайды. Кімге тағайындалғанын зерттейді. Нақты адаптация және шектеулер. Нормативті сілтемелер. Анықтамалар. Стандарттың қолданбалы қолдану – 5 негізгі, 8 қосымша, 4 ұйымдастыру процесстері. Өңдеу программасы – талаптардың талдануы, жобалау, программалау, жинау, тестілеу, орындау үшін енгізу, қабылдау. Этап бойынша жұмыстар тізімі. Этап бойынша жұмыстар мазмұны. Аспаптары.
Жобалаудың логикалық фазасы – программалық өнімнің алдын ала өңдеу фазасы. «Менде алты құл бар. Олар ақылды, талпынғыш. Менің білетінімнің бәрі, солардың арқасы. Олардың аттары: қалай және неге, кім, не, қашан және қайда» - логикалық модель құру үшін керекті сұрақтар құрамының парадигмасы. Пәндік аймақтың талдануының және сипаттамасының - этаптары, алгоритмдер мен деректер моделінің логикалық құрылуы, олардың байланысы және пайдаланушыға берілуі. Стандарттар. Техникалық тапсырма (ТТ) – өңдеуге берілетін талаптардың нәтижесі. ТТ құрамы. Өңдеудің ашылған бар әдістемесі, және олардың қазіргі заманғы құралдарда қолданылуы мен элементтері. Өңдеу этаптарын алдын ала спецификациялау және оның ТТ әсер етуі. Аспаптар мүмкіндіктері, технологиялары, жұмыс әдістемесі. Құрылымдық, модульдік және объектілік ұстанымдар – айырмашылықтары мен ұқсастықтары. Итерация, комбинирлеу және жоғарыдан төмен немесе төменнен жоғары жобалау.
UML талдау мен жобалау үрдістерінің құрамдас бөліктерін – семантикалық модельдер, синтаксикалық нотация мен диаграмманы, стандартизациялаудың сәтті талпынысы.
UML диаграммалары және класстар диграммасын құру тізбегі. Rational Rose – UML әдістемесін тарату аспабы. Ұқсас есептерді шешу үшін қолданылатын басқа да визуальды аспаптар. Өңдеу функцияналдығын сипаттау – қолдану варианттар диаграммасы (талаптар және шектеулер), функция орындалу реттері – әрекеттердің тізбектер диаграммасы (талаптар және шектеулер), өңдеу элементерінің бір-бірімен байланыс және бар болу сипаттамасы – кооперативті диаграммалар (талаптар және шектеулер). Интерфейсті жобалау. Объектілік жобаның өңделуі, ОМ 6 қосымшасына сәйкес, негізінен «прецеденттер диаграммасы» (ПД) немесе, екінші аталуы – ''Қолдану варианттар диаграммасы'' (ҚВД) басталады. Диаграмма прецедент барлық қалған жоба диграммалары үшін арналып жасалады. Ал оның екінші аталуы, негізінен, оның атқаратын рольін толық көрсетеді деп айтуға болады – пайдаланушы жүйесінің қолдану варианттар диаграммасы (актерлар, әрекет жасаушы объект). Сонымен бұл диаграмма негізінен, егер бұл ұстанымды Коуда (Сoad) атымен беріп орындайтын болсақ, онда жобалаушы сұрақтарына жауап ретінде - кім, қашан және не істегендігін білуге болады. Келесі диаграмма – ''Тізбек диаграммасы'' – Қ.В. (жеке қолдану вариантын орындау) орындауды жеке түсіндіреді (Қ.В.). Бұл диаграммада, егер Коуда әдістемесін қолданатын болсақ, онда актер вариантты орындау кезінде кіммен (немен) байланысқандығы көрсетіледі. Бұл диаграммада Қ.В. орындау уақыты анықталады, ол жүйеге нақты уақыт (RTS) жүйесінің қалай қызмет көрсететіндігін көрсетеді және жүйе, ON-LINE типінде, реакцияны шектеумен ерекшеленетіндігін де көрсетеді. Бұл диаграммада вариантты қолданушылардың арасындағы өтулер қолданушы әрекетімен анықталады. Сонымен қолданылатын Қ.В. объектіге кандидат (немесе объект атрибуты) болып табылады, ал ол орындайтын әрекет – объектінің әдісінің кандидаты болып табылады. Сондықтан, диаграмма объектілерді анықтаудың негізі болып табылатындығын айтып кетуге болады. Бұл диаграммада қолданушылар ретінде интерфейстің қолданылып отырған элементтерін және басқа ақпараттық объектілерді алуға болады.
Объект нақты немесе абстрактылы мән ретінде болады. Объект дегеніміз – программалық қосымшада нақты бір шекаралар, мағыналар және мәндермен берілген түсінік немесе абстракция.
Жүйенің әрбір объектісінің үш сипаттамасы болады- жағдайы, тәртібі және біркелкілік белгісі. Объект жағдайы атрибуттар қасиеттерінің жиынтығы және басқа абстракциямен байланыс арқылы анықталады. Мінез-құлық сипаттамасы объектінің функционалдық өмірін қамтуы, басқа объектер сұранысына әсерін зерттеп және операциялар жиыны түрінде іске асырылады. Біркелкілік белгісі объектінің әмбебаптығын анықтайды – басқа объектілермен бірдей болған жағдайда даклас объетілер тобын ортақ (атрибуттар), қасиеттер, мінез-құлық (функционалдар), семантика және басқа объектілер мен байланыс арқылы анықтайды. Класты басқаша объектіні құруға арналған шаблон деп те атауға болады. Әрбір объекті тек бір кластың данасы болып табылады. Класты құрған кезде оны құжаттандыру керек. Сипаттама класс құрылымын емес, оның мәнін беру керек.
Ratіonal Rose өнімдерінің сериясы құрастырушыны нақты уақыт жүйелерінде және «клиент/сервер» орталарында қолдануға жарайтын және қазіргі кездегі бизнес талаптарын қанағаттандыратын тиімді де сенімді шешімдерді қабылдауға көмектесетін визуалдық модельдеудің толық құралдар жиынымен қамтамасыз етеді. Ratіonal Rose құралдары біркелкі стандарттарға негізделген және модельдеуді, оларға жақын сфералардағы бизнес-процестерді оптимизациялауға талаптанатын, компьютерлік ғылымдармен онша таныс емес тұлғалармен қатар, программалық қолданбалардың логикасын модельдеу құралдарын қажет ететін мамандар үшін оңай етеді.
Келесі қолданылатын RR – мен берілген диаграммаларға - кооперативтік диаграммаларды жатқызуға болады, - олпар негізінен тәртіп детализациясы үшін қолданылады, олар уақиғалар аймағын және олардың арасындағы байланысты анықтайды, қосымша қолданушыларды анықтайды, олардың жалпы және мінездемелік анықталарын береді – яғни соңғы «Класстар диаграммасын» - салу үшін керекті деректердің барлығын алуға мүмкіндік береді. Класстар диаграммасы объектілер абстракциясы және тізімі негізінде құрылады, олар тізбектер диаграммасында қолданылған қолданушылармен анықталады, ол итерациялық өзгерістерінен алынады.
Атрибуттарды, әдістерді, қасиеттерді, оқиғаларды, кластарды анықтау. Класстар диаграммасы – класстар арасындағы байланыс - өзгешелігі және көрсетілуінің элементтері.
Алгоритмдер және ақпараттардың берілу моделін жобалау әдістемесі.
Пәндік аймақтың сөздігін құру – мәтінді сипаттама, керекті заттарды белгілеу және олардың идентификациясы, таблицалар – заттар мінездемесі, оларды қолданудың шарттары. Декомпозиция және құрылымдау әдістері. Құрылымдық деректерді декомпозициялау үшін реляциялық кестелердің қалыптастыру әдістемесі. Графтар және ақпараттық модельдеу үшін тізбекті және паралельді қолданылуы. Екі жақты графтар – заттар моделі – тәртібі. Циклдар және екіжақты графтағы шынжырлар. Тәртіп және деректер ағашы, деректер және ағындар функциялары. Желілік моделдер және фреймдер. Формалар және панелдер – жоба контейнерлері. Мәтіндік редакторлар. Аспаптық құралдардың турбо элементтері – өңдеудің жылдамдығы.
4, 5 дәріс. UML. Өңдеудің функционалдығын сипаттау. Аспаптары мен әдістері
Дәріс мақсаты: функционалдық өңделуінің сипаттамасын және өңдеу аспаптары мен әдістерін қарастыру.
«АЖ құрудың бастапқы этаптарында біз автоматандырғымыз келіп жатқан ұйым қалай жұмыс істейтіндігін ұғынып алған жөн. Ол ұйымда жұмыс істеушінің бірі де оны толық білмейді, сол үшін АЖ құрар кезде соны анықтап білу керек. Ұйым жетекшісі оны толық біледі деуге болады, бірақ ол әрбір жұмысшының ісін ашып айта алмауы мүмкін. Ал қатардағы жұмысшы өз жұмысына жауапты ол да басқалар жайында ақпараттарды бірмейді. Сондықтан ұйым жұмысын сипаттау үшін модель құру керек. Міне BPwin, сол моделді құру үшін керек – функционалдық модель (немесе процестер моделі). Әдетте бірінші ұйым жұмысының қызметтері жайындағы модель құрылады -"AS-IS" (қалай бар, сол түрде). Функционалдық модельдің талдануы оның кемшіліктерінің орнын және жаңа бизнес - процестің артықшылықтарын, сонымен қатар ұйымның бизнес құрылымы қандай өзгерістерге ұшырайтындығын толық білуге мүмкіндік береді. Модельден табылған "AS-IS" кемшіліктерді, "TO-BE" (қандай болуы керек) моделі арқылы жоюға болады – ұйымдағы бизнес – жоспарлардың жаңа моделі. Бизнес – жоспарларды моделдеудің ыңғайлы тілі болып IDEF0 табылады, ол 20 жыл бұрын Дугласом Россом (бұрын SADT - Structured Analysis and Design Technique деп аталған) жасалған. SADT әдістемесі Дэвид А.Марк және Клемента МакГоуэнаның "Методология структурного анализа и проектирования SADT" (Метатехнология баспаханасы, 1993) кітабында толық берілген.
SADT революция негізінде 60 жылдың аяғында пайда болған. Бұл кезде көпшілік мамандар бағдарламаның қамсыздандырумен айналысты, көпшілігі басқару және қару-жараққа бақылау жасап телефон байланысында қолданылатын аналогтық жүйемен бағдарламаның қамсыздандыру, ірі масштабтық жүйені құру және күрделі тапсырманы шешуге тырысты. Сол кезде ірі масштабты жүйені құрумен айналысқан мамандықтар үлкен реттелушілік керек екенін мойындады. Бұл түрде өңдеушілер жүйені құру процесін өңдеп оны келесі фазаларға бөлді:
1) Анализ – жүйенің жұмысының анықтамасы.
2) Жобалау – жүйелерді және өзара әрекетін анықтау.
3) Реализация жүйені бөлек-бөлек өңдеу бірігу – бір бүтінге жүйенің бірігуі.
4) Тестлеу – тексерісі.
5) Құрылғы – жүйенің әрекетке енгізілуі.
6) Функциялау – жүйенің қолданылуы.
Бұл сәйкестілік әрқашан итерациялық орындалған себебі жүйе толықтай қолданушылардың қажетін қанағаттандырмады.
Сонымен қатар бұл модельмен бағытталынған жүйенің басқаруында әрқашан қиындықтар туып отырады. Жүйенің берілуінен соң туындаған эксплуатациялық шығындар құрылған жүйенің шығыны ретінде жедел жылдамдықта өсе бастады. Кейбіреулері жүйені құру кезінде пайда болған қателіктерге тиісті эксплуатациялық шығындар өсті деп санайды. Зерттеу бойынша жүйедегі қателіктердің көпшілік проценті анализ және жобалау процесінде пайда болды. Мысалы, жобалау стадиясының қателіктерін түзету екі есе тұрады тестлеу стадиясында он есе, ал жүйенің эксплуатациясында жүз есе қымбат, анализ стадиясына қарағанда. Қателікті тапқанда шамамен екі есе көп уақыт кетеді, ал оны түзетуіне шамамен бес есе кетеді. Сонымен қатар қолданушылардың өзінен анализ қателігі және жобалаудан жиі қателіктер кетіп отырады. Жүйені құру кезінде бірнеше мәселелер туындады. Бірлік шешім болмады. Қолданушылардың өңдеу процесіне бақыланбады. Сәйкестілік тексерісі орынды жүргізіледі және түбегейлі жоқ болады. Бір этаптың нәтижесі екіншісімен сәйкес келмейді. Процесс қиындықпен бағалауға берілді сапалық және сандық жағынан. Жүйені құрушылар құрылымдық бағдарламалау типті әдістемесін қолданғанда және жоғарыдан төмен жобалағанда олар қойылған тапсырманы шешеді немесе жаман қойылған тапсырманы немесе жақсы қойылған тапсырманы шешеді. Сонымен қатар жүйені құру кезіндегі қателіктер аппараттық құрылғы бағдарламалық қамтасыздандыру көмегімен оңай табылып отырады. Жиі бұл қателіктер функцияналды спецификацияны немесе спецификациянымен және жобалау нәтижесінің арасындағы келіспеушіліктер зерттеліп отырады. Жобалаушылар жүйенің күрделілігін білді. Жүйенің күределілігі және көлемінің өсуі өмірлік реалия болып табылады. Бұл алдыңғы сұранысты қабылдау керек болды. Соңынан тезис пайда болды: анализ әдісінің дұрыстығы, тиімді тұрысы, өнідірістік және қауіпсіздігі. Кең профильді жүйенің кілттік мәселесін шешу үшін процестің ертеректі стадиясынан қолданылуы үшін жаңа әдістер қажет болды. SADT сияқты әдістер қарастырылған мәселелерді дұрыс түсіну үшін жүйе құрудың бастапқы этапына қажет болды. Ал бұл құруға кеткен шығындарды қысқартып оның ыңғайлылығын көтереді. SADT – бұл өңдеушілер мен қолданушылар арасындағы қатынасты жақсартып бастапқы құрылымы үшін қателіктерді азайту әдісі.
SADT моделінің шынайы және графикалық тілдер қолданылады. Жүйені жазушы дамдар шынайы тілдің нақты жүйесі қызмет етеді, ал графикалық тілдер көзіне – SADT әдістемесінің өзі. Әрі қарай сіз SADT графикалық тілі модельдің шынайы тіліне нақты семантиканы және құрылымды қамтамасыз етеді. SADT графикалық тілі SADT жүйені жазуға мүмкіндік береді, анықталған және бір мәнді түрде шынайы тілді ұйымдастырады.
SADT моделі жүйенің функциясына немесе оның объектісіне дайын болады. Функцияға бағтталған SADT моделін функционалды модель деп атауға қабылданған, а) жүйе объектісіне бағытталған – мәліметтер модель деп аталады, функционалды модельдер өзінің ретімен арақатынасын жүйе объектісі арқылы кескінделеді функция жүйесін бөлшектеу деңгейімен беріледі. Мәліметтер моделі функционалды моделдерге бағытталған жүйені функциямен байланысқан жүйе объектісінің жазылуын береді. SADT толық әдістемесі күрделі жүйенің анық жазылуы үшін модельдердің көпшілігі құрылуына мүмкіндік береді. Бұл кітап функционалды модельдер құруы үшін арналған. SADT мәліметтер моделі көмегімен және көпшілік модельдер құру бұл кітаптың жиегінен шығады.
SADT блоктары ешқашан диаграммаға кездейсоқ түрде орналаспайды. Диаграмма авторы оны түсінуі бойынша маңыздылық деңгейінде орналасады. Осыған қатысты реттіелік SADT-да доминирленген деп аталады. Доминирлену бір блок екінші диаграмма блогына әсері ретінде түсініледі. Мысалы, диаграмманың ең доминирленген блогы болып бірінші қажетті сәйкестілік блоктарының функциясы немесе басқа функцияларға әсер етуші жоспарланған немесе бақылаушы функциялар болды мүмкін.
Көпшілік доминирленуші блоктары әдетте диаграмманың жоғарғы сол жақ бұрышында, ал аз доминирленушісі – оң жақ төменгі бұрышында орналасқан. Беттегі блоктың орналасуы доминирленудің авторлық анықталуын бейнелейді. Мұндай түрде диаграмма топологиясы қандай функциялар басқаларына қарағанда әсер ететінін көрсетеді. Бұны белгілеу үшін SADT аналитигі оның доминирленуі бойынша блоктары кері номерлеуі мүмкін. Доминирлеу реті әрбір тікбұрыштың оң жақ төменгі бұрышында орналасқан санмен белгіленеді.
SADT-да блоктар кері нөмірленген болуы керек. Блоктар нөмірі жүйелік функция үшін бірмағыналық болуы қажет және модельдің иерархиясында бұл функциялар автоматты түрде ұйымдастырады. Блоктар нөмірін қолдана отырып және оның әсерін бағалай отырып, аналитик функционалды доминирлену принципі бойынша модель ұйымдастырады. Бұл әрбір функцияның иерархиялық ретіне келісуге мүмкіндік береді. Сондықтан біз міндетті түрде олардың доминирлену ретіне сәйкесінше блоктарды нөмірлеу мүмкіндігін береміз.
SADT диаграммасы бір-бірімен 3-6 дейінгі блоктардан тұрады және модель құрылымының бірнеше түрлері бар. Бір диаграммасын айыра білу үшін С-нөмірлері қолданылады. Диаграммадағы блоктар жүйелік функцияларды көрсетеді, ал иіні көптеген объектілердің жүйесін көрсетеді. Көп кезде блоктар диаграммасында домирленген тәртібі бойынша, яғни бір-біріне қатысты маңыздылығымен орналасады. Блоктармен қосылған иіндер, объектілер жиынтығын көрсетеді және бірнеше бұтақтарға бөлінеді, әртүрлі күрделі әдістермен қосылады. Бірақта иіндер барлық бөлінген және қосылған жағдайда, олар өздері көрсетілген объектілерді сақтау керек.
SADT диаграммасы белгіленген объектілер декомпозициясы болып табылады. Объект блок және оның иіндерімен шектеледі. Шектеуі бар диаграммаларды ата-аналық диаграмма, ал ата-аналық нөмірлі декомпозирленген блок, ұрпақ диаграммасы деп аталады. Ата-аналық диаграммалары және ұрпақ диаграммаларын С- нөмірлерімен байланыстырамыз. Осы модель өзінің актуальдылығын сақтайды.
ICOM кодтары, ұрпақ диаграммамен ата-аналық диаграммаларды қосу үшін қолданылады.
Егер модельде диаграммаларды оқу үшін өте қиын болса, ол үшін техникалық қабылдағыш «иіндердің тоннельге кіруі» типін қолдануға болады.
Бағалық талдау.
Бағалақ талдау (ABС) кең тараған әдістеме болып табылады, ол халықаралық корпорациялармен және мемлекеттік ұйымдармен (соның ішінде АҚШ департаментімен де қолданылады) ұйымдағы нақты шығындарды іздеу үшін қолданылады. Бағалық талдау есеп беру, шығындардың деректерін жинау, жұмыспен байланысты шығындарды жинау сияқты талдаулардан тұрады. Осы талдаулардың арқасында жалпы процесске кететін шығынды талдап шығуға болады. АBC жұмыс моделіне негізделген, өйткені сандық баға қою мүмкін емес. ABC арқылы шыққан шығындарды анықтап ұйымды қайта құру кезінде оған қандай модель қолдану керек екендігін толық анықтауға мүмкіндіктер туады (Business Process Re-engineering, BPR). Бағалық талдау арқылы келесі жұмыстарды да жүргізуге болады:
- ұйымдық өнімнің нақты бағасын анықтау;
- тапсырыс берушіні ұстап тұру үшін бағаны анықтау;
- бірінші кезекте көңіл бөлу керек жұмыстарды анықтау және бағасы қымбат жұмыстарды табу және т.б.
ABC әдістемесі келесі негізгі сипаттамалардан тұрады, шығын объектісі (жұмыстың орындалу себебі), шығынды жүргізу (кіріс мінездемелері және жұмысты басқару, оның қанша уақытта және қалай орындалатындығы жайындағы ақпараттар), және шығын ортасы (шығын статьялары). BPwin-да осы жұмыстардың барлығына көңіл бөлінген, бағлық талдау жасаудан бұрын қанша ақша кетеді және қанша уақытта орындалатындығы талданады, одан кейін шығын ортасы табылады (cost centers). Нәтижесінде, әрбір жұмыс үшін декомпозиция схемасы бойынша оның істелу ұзақтығы табылады (duration), және жалпы жұмыстың істелуіне кететін уақыт есептелінеді (frequency) және әрбір шығын ортасына кететін ақша есептелінеді, яғни әрбір жұмысқа жұмсалатын ақшалар шығын статьясымен беріледі.
Олар өңдеудің функционалдық мүмкіндіктерін сипаттау үшін және программаға қойылатын талаптардың спецификациясы үшін қолданылады. Ақпараттық объектілердің логикалық моделін құру әдістемесі. Прототип немесе бос парақ, элементтер компоновкасы және қосылуы, графиканың текстілік көрсетілілімі, шығу файлдарының форматы және экспорты.
6 дәріс. Кластар диаграммасын құру. Әдістері, технологиялары, аспаптары
Дәріс мақсаты: класс түсінігін қарастыру.
Класс (Class) ортақ қасиетттері (атрибуттары), тәртібі (функциялары), семантикасы және басқа объектілермен байланысы бар объектілер тобын анықтайды. Кластың объектіні құруға арналған шаблон ретінде қарауға болады. Әрбір объекті қандайда бір ғана кластың нұсқасы мысал ретінде келесідей сипаттамалары бар ‘курсты ұсыну’ класс анықтамасын қарастырайық:
1) Атрибуттар – «сабақты өткізетін орын», «сабақты өткізетін уақыт», «курстың аталуы», «курс нөмірі», «ұсыныс нөмірі».
2) Функциялары – «сабақты өткізетін орынды анықтау», « сабақты өткізетін уақытты анықтау», «студентті тіркеу», «студентті тіркеуді тоқтату».
«Курстық ұсыну» класының нұсқасының орнына ‘алгебра 101, 1- бөлім’ және ‘алгебра 101 , 2- бөлім’ объектілерінде алуға болатын еді, себебі олардың да әр қайсысының нақты атрибуттурының жиынтығы және ортақ функционалдық сипаттамалары бар.
Дұрыс құрылған класс тек бір ғана абстракцияны бере алады. Мысалы, студент туралы мәлімет сақталған, сонымен қатар барлық оқу барлығында студент өткен курстар тізімі функциясы көрсетілген класты сәтті құрылған деп айта алмаймыз, өйткені ол екі әртүрлі операциялар тобын қамтиды. Сондықтан мұндай класты екіге – «студент» және «студент өткен курстар» бөлсе жақсы болар еді.
Класстың атауы үшін пән облысына сәйкестендіріліп қабылданған терминдерді қолданған дұрыс. Класс аты ретінде жобаланатын түсінікті толығымен сипаттай алатын зат есіміңіз жекеше түрі қолданылады. Кейде қысқартылған атауларда қолданылып, класты құжаттандырғанда міндетті түрде мағынасын ашып көрсету керек. Егер аббревиатура бірдей мағыналы емес интерпретация жіберсе, онда сәйкесінше айтылудың толық түрін қолданамыз. Объектілер мен кластар арасындағы ерекшелікті табу қиын.
UML–да класс зоналарға бөлінген тіктөртбұрыш түрінде кескінделеді. Жоғары зонада класс аты, ортасында оның құрылымы (атрибуттар тізімі) оның астындағысында тәртібі сипаттамаларын анықтайтын функциялар беріледі.
1 сурет
Класты қалай құрады:
1) Browser терезесінің Logіcol Vіew элементіне тышқан сілтеушіні қойып, контекстік менюді белсенді ету үшін оң батырмасын шертеміз.
2) Менюді New-Class элементтерін таңдау; Browser терезесінде кескінделген ағаш (бұтақ)жаңа класқа сәйкес келетін New-Class элементімен толықтырылады.
3) New-Class элементін таңдап және кластың қажет атауын енгізіп, оны өзгертеміз.
CASE – құралдарына байланысты ақпараттар біздің ойымызша кәдімгі бір программалаумен тығыз байланысты зат сияқты. Америкада, бәсекелестіктің күшті болуына байланысты, CASE – құралдар программалық қамтаманы өңдеуші фирмаларды басып отыру үшін қолданылады. CASE – құралдардың дамуы объектілі – бағытталған ПҚ өндеу технологияларына байланысты. Осы кезде объектілік модельдеу технологиялары да пайда бола бастады Booch, OMT, UML, олар өз алдына программалаумен байланыстыруға мүлдем келмейді. Бүгінде алдынғы қатардағы CASE-жүйе болып Rational Rose корпорациясымен шығарылған Rational Software алынады. Rational Rose жүйесі Unified Modeling Language (UML) тілін қолдана отырып модульдер құру үшін пайдаланылады. Айталық, UML объектілі – бағытталған стандартты тілі болып қалыптасуы Rational Software – нің арқасында деп айтсақ та артық емес, ол UML-ді қолданатын программалық өнімдерді шығарып қана қоймай, сонымен қатар UML тілінің спецификациясын құратын және жаңартатын CORBA таратылған есептеулермен байланысты технологиялар Object Management Group (OMG) –пен де жұмыс жасайды, және Rational компаниясында үш, UML тілін және объектілі – бағытталған өңдеуді құрушылар жұмыс жасайды. Бұлар Гради Буч, Айвар Джекобсон және Джим Рамбаух.
Rational Software Rational Rose компаниясының CASE-жүйелері коммерциялық ПҚ құру үшін барлық жерлерде және әйгілі программалау тілдер Java, Cu++, Смолток, Ада, Visual Basic, Power Builder жәнен Forte қолданылады. Сонымен қатар, Rose пакеті CORBA и Data Definition Language (DDL) қосымшалары үшін, Interface Definition Language (IDL) тілдеріндегі сипаттамаларды генерациялауға, деректер базасына қатынау қосымшалары соның ішінде Оracle 8-ге қатынауға мүмкіндік береді. Айталық, соль немесе басқа программалау тілін қолдауы Rational Rose пакетінің қай редакциясы екендігіне байланысты.
Мысалы, қарапайым - Rose Modeler Edition пакетіне қатты талаптар қоюға болмайды. Ал оның орнына Rose Enterprise Edition барлық талаптарға сай деп айтсақ болады
Айталық, Rose жүйесі - визуальды моделдеу жүйесінде жақсы орын алады, оны қолдана отырып құрылып отырған қосымшаның құрылымын құруға, оның орындамалық текстін генерациялауға және паралельді өңделіп отырған жүйенің құжаттаымен жұмыс жасауға болады. Rational Rose көмегімен com модульдегі кері талдау базасы негізінде жаңа модельдер құруға немесе қолданбалы программа текстін және кітапханалар кластарын анықтауға болады.
Rational Rose артықшылықтары:
1) Қосымшаның өңделу циклын қысқарту.
2) Программист жұмысының өнімділігін арттыру.
3) Бизнес және пайдаланушыларға байланысты тапсырыс берушілердің программа құрудағы сапалық бағасын жақсарту.
4) Үлкен жобалар және жобалар тобын құруа алу мүмкіндіктері.
5) Бұрын құрылған ПҚ қолдана алу және олардың құрылымы мен компоненттерін өзгерте алу мүмкіндіктері.
6) UML тілі әртүрлі бөлімдер мен өндірушілер арасындағы әмбебеп "көпір".
Жүйенің кемшілігі, басқа да бөліктеп жинау жүйелері сияқты мұнда да көп керек емес бөліктер көп. Яғни Rational Rose жобаның базалық құрамдас бөлігін жасайды.
Coad аспаптары және әдістемесі. Программалық жүйе жобаларын өңдеу мысалы және әдістемесі. Тиімді объектілік модельдер құрудың практикалық құралдары - стратегиялары және бейнелері. Стратегиялар: әрекеттер және компоненттер; жүйенің мінездемелік қасиеттерін және мақсаттарын анықтау; объектілерді таңдау; міндеттерін анықтау; сценарий көмегімен динамикасын өңдеу; жаңа стратегияларды және бейнелерді табу. Бейнелер: фундаментальды; транзакция; агрегаттар; жоспарлар; байланыстар.
7, 8 дәріс. Өңдеу тілін, тарату ортасын және өңдеу аспаптарын анықтау
Дәріс мақсаты: программаны таратудың виртуалды ортасының ерекшеліктері және программаны өңдеу кезіндегі олардың есептелуін; программалау тілдері және тілдік жүйелері – өңдеу ортасын және программаның таратылуын (4 және 5 GL деңгейі); тілдік құралды таңдау және керекті программалау деңгейін анықтауын қарастыру.
Ауыстыру интерфейсі және компоненттерді қабылдаудың пайда болғанына біраз уақыт болды. Ол қосымшаны орындау кезінде басқарушы екі элементтің қарым-қатынасын қамтамасыздандыру үшін қолданылады. Бұл кезде басқа да керекті операциялар орындала береді. Таратудың оңайлылығына қарамастан бұл әдісті көп программистер (әсіресе үйренушілер) түсініксіз деп санайды. Бірақ оған қарамастан Drag-and-Drop қолдану өте пайдалы және тартуда жеңіл болуы мүмкін. Механизм жұмыс жасау үшін, керек бейнеге байланысты екі сәйкес басқарушы элементті қалыптастыру керек. Олардың бірі таратушы (Source), екіншісі — қабылдаушы (Target). Бұл кезде таратушы ешқайда ауыстырылмайды, тек регистрацияланады. Ескерту бір басқару элементі қабылдағыш та және таратқыш та бола алады. Пайдаланушы тінтуірдің көмегімен басқару элементерін керек жерге орналастыра алады. Бұл текста, қасиеттердің мәні (бір редактордан екінші бір редкторға ауыстыру, интерфейсті ауыстыру, шрифтін ауыстыру және текстің өзін ауыстыру); файлдарды және суреттерді ауыстыру; қарапайым ауыстыру және т.б. Windows-тағы Drag-and-Drop ауыстырулары — файлдар мен дискілер және папкалар арасындағы ауыстыруларды да орындайды.
1) Drag-and-Drop барлық механизмдері TControl базалық классында таратылған, ол барлық барлық басқару элементтерінің түбірі болып табылады. Механизм жұмысының маңызы неде? Delphi компоненттер палитрасындағы кез – келген басқарушы элемент Drag-and-Drop механизіміндегі таратушы болып табылады. Оның ауыстыру этапындағы бастапқы тәртібі оның қасиетне байланысты болады type TDragMode = (dmManual, dmAutomatic); roperty DragMode: TDragMode;
2) dmAutomatic мәні тінтуірдің сол жақ басқышының басылуына негізделген. dmManual мәні (үнсіздікпен қойылған) механизмнің қолмен қосылуын күтеді. Бұл режім сол жақ басқыш басқа да бір басқа жұмыстар жасау керек болса қолданылады. Ауыстыруды инициализациялау үшін procedure BeginDrag(Immediate: Boolean; Threshold: Integer = -1) әдісі қолданылады;
3) immediate = True параметрі механизмнің тез арада орындалуын қамтамасыздандырады. Ал оның мәні False болса онда ол тек тінтуірді қолданып ауыстырған кезде ғана қосылады, ол Threshold параметрімен анықталады. Механизнің қосылғандығы тінтуірдің көрсеткішімен сигналданады — ол курсорға өзгереді, property DragCursor: TCursor қасиетінде анықталады;
4) procedure DragOver(Source: TObject; X, Y: Integer; State: TDragState; var Accept: Boolean);
Ол курсор ауысқан кезде Drag-and-Drop режімінде осы компонентпен ауысады. Егер Accept параметрінің мәні True болса, онда берліген компонент қабылдағыш болады. Таратқыш source параметрімен анықталады. state параметрі тінтуірдің жылжуы жайындағы ақпаратты береді:
1) type TDragState = (dsDragEnter, dsDragLeave, dsDragMove);
2) dsDragEnter — көрсеткіш компоненттің үстінде пайда болды; dsDragLeave — көрсеткіш компонентті тастап кетті; dsDragMove — көрсеткіш компонент үстімен жылжып барады.
Қабылдаушы кейбір жағдайларды ескеру керек, егер қабылдаушы жұмысын қабылдаушының үстінде аяқтаса. Онда ол үшін өңдеу - әдісі қолданылады.
type TDragDropEvent = procedure(Sender, Source: TObject; X, Y: Integer) of object;
property OnDragDrop: TDragDropEvent;
ол тінтуірдің сол жақ басқышын жіберген кезде шақырылады. Қабылдаушыға немесе таратушыға қатынауды сәйкесінше Source және Sender параметрлері қамтамасыздандырады. Тінтуір координаттары X және Y параметрлеріне жіберіледі.
type TEndDragEvent = procedure(Sender, Target: TObject; X, Y: Integer) of object;
property OnEndDrag: TEndDragEvent;
Таратушыда және қабылдаушыда сәйкесінше Sender және Target параметрлерімен анықталады. Тінтуір координаттары X және Y параметрлеріне анықталады. Программаны тоқтату үшін EndDrag таратушының әдісі қолданылады:
procedure EndDrag(Drop: Boolean); Параметр Drop = True ауыстыруды тоқтатады. False мәне ауыстыруды үзеді.
Енді өткенімізді нақтылайық, практикада мысал қарастырайық. Жобада DemoDragDrop - Drag-and-Drop механизімімен текстілік редакторлар арқылы тексті ауыстыру таратылған және оларды форма бойынша панельдерді ауыстыру.
Листинг 1. implementation - DemoDragDrop жобасының негізгі формасының секциясы
implementation
{$R *.DFM)
procedure TMainForm.EditlMouseDown(Sender: TObject; Button: TMouseButton; Shift: TShiftState; X, У: Integer);
begin if Button = mbLeft
then TEdit(Sender).BeginDrag(True);
end;
procedure TMainForm.Edit2DragOver(Sender, Source: TObject; X, Y: Integer;
State: TDragState; var Accept: Boolean);
begin
if Source is TEdit
then Accept := True
else Accept :<= False;
end;
procedure TMainForm.Edit2DragDrop(Sender, Source: TObject; X, Y:
Integer);
begin
TEdit(Sender).Text := TEdit(Source).Text;
TEdit(Sender).SetFocus;
TEdit(Sender).SelectAll;
end;
procedure TMainForm.EditlEndDrag(Sender, Target: TObject; X, Y: Integer);
begin if Assigned(Target)
then TEdit(Sender).Text := 'Текст перенесен в ' + TEdit(Target).Name;
end;
procedure TMainForm.FormDragOver(Sender, Source: TObject; X, Y: Integer;
State: TDragState; var Accept: Boolean); begin if Source.ClassName = 'TPanel'
then Accept := True
else Accept := False;
end;
procedure TMainForm.FormDragDrop(Sender, Source: TObject; X, Y: Integer);
begin
TPanel(Source).Left := X;
TPanel(Source).Top := Y;
end;
end.
Біржолды Edit1 редакторы үшін таратқыштың әдіс - өңдегіштері анықталған. EditiMouseDown әдісінде тінтуірдің сол жақ басқышын басу және ауыстыру механизмі өңделеді. Өйткені Edit1 үшін DragMode қасиетінің мәні dmManual болады да, компонент ешбір қиындықсыз фокусты алу және тексті редакторлауды қамтамасыздандырады. EditiEndDrag әдісі таратқыштағы ақпаратты бейнелеп ауыстыруды қамтамасыздандырады. Edit2 компоненті үшін қабылдағыштың әдіс - өңдегіштері анықталған. Edit2DragOver әдісі таратқыш класын тексеріп қабылдауға рұқсат береді не бермейді. Edit2DragDrop әдісі таратқыштан мәтінді қабылдағышқа ауыстыруды орындайды. Ескерту Tedit-тің екі копонентіне көңіл бөліңіз, олар бір уақытта таратқыш та қабылдағышта бола алады. Ол үшін бұлардың әрқайсысы бірін – бірінің әдіс - өңдегіштерін қолданады. Ал әдістердің орныдалатын коды Tedi классының форма экземплярын өңдеуге қалыптастырылады, Drag-and-Drop қабылдағышы, Panel2 панелінің ауысуын қамтамасыздандырады, ол таратқыш ролінде қолданылады. FormDragOver әдісі кез келген компоненттерді қабылдаудан қорғайды, панелдерден басқа. FormDragDrop әдісі компоненттердің ауысуын орындайды. Панелдің әдіс - өңдеуіштері болмайды, өйткені ол dmAutomatic режімінде жұмыс жасайды және қосымша ауыстыруды аяқтауды қажет етпейді.
Drag-and-Dock байланыстыру интерфейсі. Ол негізі Delphi 4 пайда болды. Ол да Microsoft өңдеушілерімен MS Office, Internet Explorer және басқа өнімдерінде қалқып шығатын аспаптар панелінде "қарастырылған". Кейбір басқарушы элементтер (атап айтсақ — xwinControl классының түбтері) басқа басқарушы элементтер үшін бір доктан екіншіге тінтуір арқылы өтетін динамикалық тартылатын мүмкіндігі бар жинақтаушы (доктар) бола алады. Кез – келгенг затты ауыстыруға болады — статикалық текстен бастап формаларға дейін. Drag-and-Dock техникасын қолдану мысалын Delphi өңдеу ортасы өзі береді — оның көмегімен экран бетінде кез келген аспаптарды біріктіруге болады, мысалы объектілер инспекторы және жоба менеджері сияқты. Drag-and-Drop ауыстыру технологиясындағыдай, Drag-and-Dock мұнда да таратудың екі нұсқасы қолданылады: автоматты және қолмен. Бірінші жағдайда керек мәндерді бірнеше қасиеттерге орналастыру керек, ал қалған жұмысты VCL коды өзі жасайды; ал екіншісінде, атында көрсетілгендей, барлық жұмыс программалаушыға байланысты жүреді. Сонымен, Drag-and-Dock енгдіру үшін не істеу керек? Объектілер инспекторында DragKind мәндерінің қасиетін dkDock ауыстыру керек, aл DragMode қасиетін — dmAutomatic ауыстырамыз. Енді бұл басқару элементін бір жинағыш – доктан басқа доктарға ауыстыруды орындауға болады. Басқа компоненттердің (доктардың) жинағышы ретінде TwinControl түбірі алынуы мүмкін. Оның Docksite қасиеті бар, оны True-ге орнату басқа компоненттерге ауысуды орындайды. Егер бұл кезде тағы AutoSize қасиетін де True-ге орнатса, онда док автоматты түрде керек мөлшерге масштабтала алады. Әдетте бұл үш операциямен міндетті минимальды жиын ауыстырылады.
Әрине, программалаушы үшін бұл процессті бақылау мүмкіндігі қарастырылған. Әрбір ауыстырылатын басқару элементінің оны бастау кезінде және аяқтау кезінде пайда болатын екі уақиғасы болады:
type TStartDockEvent = procedure(Sender: TObject; var DragObject: TDragDockObject) of object;
TEndDragEvent = procedure(Sender, Target: TObject; X, Y: Integer) of object;
Бірінші әдістегі sender — бұл ауыстырылатын объект, aл DragObject — арнайы объект, ауыстыру процессі құрылған уақытта пайда болады және оның қасиеттерінен тұрады. Екінші әдістегі sender — бұл да ауыстырылатын объект, aл Target — объект-док. Док та ауыстыру кезіндегі уақиғаларды қамтиды:
type TGetSitelnfoEvent = procedure(Sender: TObject; DockClient: TControl;
var InfluenceRect: TRect; MousePos: TPoint; var CanDock: Boolean) of object;
TDockOverEvent = procedure(Sender: TObject; Source: TDragDockObject;
X, Y: Integer; State: TDragState; var Accept: Boolean) of object;
TDockDropEvent = procedure(Sender: TObject; Source: TDragDockObject; X, Y: Integer) of object;
TUnDockEvent = procedure(Sender: TObject; Client: TControl; NewTarget: TWinControl; var Allow: Boolean) of object;
Пайдаланушы тінтуірдің басқышын ауыстырылатын компоненттің үстіне апарып басса болғаны, оны орнынан қимылдатуға болады да, барлық потенциальды доктарға (компоненттердің, Docksite қасиеттері True-ге орналасқан болса) onGetsiteinfo қасиеті жіберіледі. Олармен бірге параметрлер беріледі: «кім жерге орналасқысы келеді» (Dockclient параметрі) және қайда (MousePos). Оған жауап ретінде док шешім хабарлама жіберуі керек, ол компонентті қабылдайды ма (CanDock параметрі) және қайда қабылдайды (infiuenceRect) немесе қабылданбайтындығы жайында хабар береді. Бұл уақиғаның көмегімен кейбір керекті басқарушы элементтерді ғана қабылдауға болады, мысалда көрсетілгендей:
procedure TForml.PanellGetSitelnfо(Sender: TObject; DockClient: TControl; var InfiuenceRect:
TRect; MousePos: TPoint; var CanDock: Boolean);
begin if DockClient is TBitBtn then CanDock := False; end;
Келесі екі жағдай да алдыңғы қарастырған Drag-and-Drop ауыстыру механизіміне сәйкес. onDockOver уақиғасы докпен ауыстырылатын компоненті ауыстырған кезде орындалады, OnDockDrop — оны жіберген кезде орындалады. Сонымен, onUnDock доктың босағандығы және басқа жерге орналасқандығын хабарлайды. Докпен және ондағы басқарушы элементтердің арасында екіжақты байланыс бар. Барлық "орналасқын" басқару элементтері векторлық Dockclients қасиетінде сақталған, ал олардың санын қасиеттерден білуге болады:
DockClientCount: s : = ' ' ; for i := 0 to Panell.DockClientCount-1 do AppendStr(s,Panell.DockClients[i].Name+#$D#$A); ShowMessage(s);
Басқа жағынан, егер басқару элементі докта орналасса, онда докқа сілтеме HostDocksite қасиетінде орналасады. Оның көмегімен элементтің қайда орналасқанын біруге болады және оның қасиетін де өзгерте аламыз:
procedure TMyForm.ButtonlEndDock(Sender, Target: TObject; X, Y: Integer); begin
(Sender as TControl).HostDockSite.SetTextBuf(pChar((Sender as TControl).Name)); end;
Компоненттерді бір орыннан екінші орынға ауыстырудан басқа оларды кез келген жерге орналастыруға болады. Бірақ TControl компоненті және оның түбірлері Windows терезелері болып табылмайды, бірақ бұл жағдай үшін арнайы терезе-жинағыштар құрылады. FloatingDockSiteClass қасиеттері міне, осы құрылатын терезенің класын анықтау үшін керек. Үнсіздікпен көптеген бұл қасиеттегі компоненттердің мәндері TcustomDockForm тең болады. Бұл — форма, ол доктың қасиеттерінен тұрады және басқару элементін басқа доктың қасына жіберген кезде құрылады. Сыртынан ол стандартты формаға ұқсайды. Егер сіз өзіңіздің қалқымалы аспаптар панеліңіз ерекше көрінсін десеңіз, онда түбірді TCustomDockForm классынан туындатыңыз және қасиетін пайда болған FloatingDockSiteCiass классымен байланыстырыңыз:
TMyCustomFloatingForm = class(TCustomDockForm)
public constructor Create(AOwner: TComponent); override; end;
constructor TMyCustomFloatingForm.Create(AOwner: TComponent};
begin inherited Create(AOwner); BorderStyle := bsNone; end;
procedure TForml.FormCreate(Sender: TObject);
begin ToolBarl.FioatingDockSiteCiass := TMyCustomFloatingForm; end;
Бұл мысалда типтік есеп шешілген — мұнда негізінен, қалқып тұрған асапаптарды алып жүруші терезенің тақырыбы болмау үшін жасалған. Мұндай панельдердің сыртқы көрінісі 1-суретте көрсетілген.
Компонентті ауыстыруды тінтуірдің көмегімен ғана емес, сонымен қатар программа көмегімен де жасауға болады. Бұл үшін екі әдіс қолданылады: ManualDock және ManualFioat. Төменде келтірілген мысалда BitBtnl атымен берілген басқышты басу custForm формасымен берілген докты MainForm.Paneil ауыстырады және оны барлық қатынауға болатын аймақтарға орналастырады (alclient теңестіру параметрі). BitBtn2 басқышын басу бұл форманы доктан босатады және оны экранның ортасына теңестіреді. UndockHeight және undockwidth қасиеттерінде басқару элементінің доктағы өзгерісі бойынша ені мен ұзындығы сақталады:
procedure TMainForm.BitBtnlClick(Sender: TObject);
begin GustForm.ManualDock (MainForm.Pane11,nil,alClient); end;
procedure TMainForm.BitBtn2Click(Sender: TObject);
begin with CustForm do begin ManualFloat(Rect((Screen.Width-UndockWidth) div 2,
(Screen.Height-UndockHeight) div 2, (Screen.Width+UndockWidth) div 2, (Screen.Height+UndockHeight) div 2) ); end;
Егер бұл тақырып жайында бәрін толық білгіңіз келсе онда useDockManager және DockManager қасиеттерін оқыңыз.
Windows реестрі және RegEdit. Программаларға қатынау жолдары және оларды санкцияланбаған қатынаудан, программалар және деректерден қорғау.
9 дәріс. Физикалық жобалау процедурасы – тәртібі, аспабы, ресурсы, құжаттары
Дәріс мақсаты: физикалық жобалау процедурасы – тәртібі, аспаптары, ресурстары, құжаттарын қарастыру.
Препроцессорлар және компилятор ерекшеліктері.
C++Builder-дің кейбір кілттік сөздері жайында, олар ANSI стандартына жатпайды. Сонымен қатар, Project | Options диалогы жайында айтамыз, онда программа компиляциясын басқаратын әртүрлі параметрлер беріледі.
Препроцессор директивалары
Препроцессорлық өңдеу процесстің бірінші фазасы деп аталатын, C/C++-тағы программаларды компиляциялайтын, бірақ C++Builder компиляторы аралық файлдарды препроцессорлық өңдеуден кейін де генерацияламайды. Бірақ, егер нәтижесінде препроцессор жұмысын көргіңіз келсе, онда срр32.ехе бөлек программасын командалық жолдан жіберіп көруге болады: срр32 myfile.c.
Макроанықтамалар.
Макроанықтамалар, әдетте макростар деп те аталады, препроцессордың #define директивасымен анықталады. #define макростарының үш түрлі формаларын атап айтуға болады: қарапайым символды анықтау, символдық константаны анықтау және параметрлері бар макростарды анықтау. Қарапайым анықтау келесі түрде беріледі: #define NDEBUG.
Мұндай директивадан кейін NDEBUG символы анықталған деп есептеледі. Ол ешнәрсені білдірмейді, бірақ жай ғана — анықталған (бос) екендігін білдіреді. Оны: #define NDEBUG 1 деп жазуға болады.
Ол кезде NDEBUG символдық константа ретінде де қолдануға болады. Сонымен, #define константаларды ғана емес, басқа текстілік көрсеткіштерді және операторлар тізбегін де анықтауға мүмкіндік береді, ол төменде берілген:
#define SHUTDOWN printf("Error!");
\ return -1
…
if (ErrorCondition()) SHUTDOWN; // "шықыру" макросты.
Кері бөлу белгісі (\) макрос келесі бетте жалғасатындығын көрсетеді. С операторларынан айырмашылығы препроцессор директивалары бір жолда орналасуы керек, егер ол орналаспаған жағдайда оның келесі жолда екендігі осы белгімен анықталады.
Ертерек анықталған макросты #undef директивасымен алып тастауға болады: #undef NDEBUG.
Бұдан кейін макрос анықталмаған деп есептеледі, одан кейінге оған қатынаулар компиляция кезіндеге қателерге алып келеді.
Алдын ала анықталған макростар.
C++Builder компиляторы автоматты түрде кейбір макростарды анықтайды. Оларды екі категорияға бөлуге болады: ANSI макростары және C++Builder-ге арналған спецификалық макростар. Алдын ала анықталған макростардың түрлері сәйкесінше 1- және 2-кестелерде берілген.
Көптеген алдын ала анықталған C++Builder макростары құрылатын компиляцияның әртүрлі параметрлерін командалық жолдан (bсс32.ехе копиляторын қолмен жіберу кезінде) бейнелеу үшін қоданылады. Осы жұмыстарды интеграцияланған ортада Project Options диалогы арқылы да орындауға болады, оны біз әлі қарастырамыз.
Параметрлері бар макростар.
Макростар тек текстік қойылымдарды ғана орындамайды. Праметрлері бар макростар С тілінің функцияларына ұқсас жұмыстарды да орындайды, мысалы:
#define PI 3.14159265
#define SQR(x) ( (x) * (x) )
#define AREA(x) (PI * SQR(x))
#define MAX(a, b) (<a)>(b) ? (a): (b))
…
circleArea = AREAfrl + r2);
cMax = MAX(i++, j++);
1 кесте – Алдын ала анықталған ANSI макростар
|
Макрос сипаттамасы |
|
|
DATE |
форматтағы литеральдық жол “mmm dd yyyy”, берілген файлдың препроцессормен өңделу күнін көрсетеді. |
|
FILE |
ағымдағы файлдың атын көрсететін жол (жақшада болады). |
|
LIME |
бүтін, ағымдағы файлдың нөмірін көрсететін жол. |
|
STDC |
1 тең, егер компилятор мен стандарт сәйкес келсе. |
|
ANSI |
(А командалық жолының – кілті). Басқа жағайда макрос анықталмаған. |
|
TIME |
“hh:mm:ss” форматындағы жол, файлды өңдеудің препроцессорлық уақыттын көрсетеді. |
|
_file_ және _line_ макростарының мәні |
#line директивасымен өзгертілуі мүмкін. |
Үшінші макроанықтағыш макростар ішіне орналасқан бола алатындығын көрсетеді. Макростың әрбір кеңейтілуінен кейін препроцессор алынған тексті жаңадан сканерлейді де, ондағы өз кезегінде макрос болып табылатын идентификаторларды анықтайды.
Жөғарыда көрсетілген анықтаулардағы жақшаларға көңіл бөліңіз. Олардан келесі тәртіптерді құрастыруға болады: әрбір параметр және барлық анықтаулар бүтіндей жақшаға алынуы керек. Әйтпесе макросқа кіру кезінде операцияның приоритетіне байланысты қателер шығуы мүмкін. Келесі жағдайды қарастырайық:
#define SQR(x) х*х binom = -SQR(a + b);
Макростың кеңейтілуінен кейін келесі жол пайда болады:
binom = -a + b*a + b;
Wіndows-та программалау АРІ функциясын (программалық қолданбаның интерфейсі) пайдаланумен негізделген. Олардың көлемі 2000-ға жетеді. Операциялық жүйенің сыртқы құрылғылар мен қорлармен өзара әрекеттестігі осы функциялар көмегімен орындалады.
2 кесте – Алдын ала анықталған C++Builder макростар
|
Макростар мәндері сиапттамасы |
|
|
ВСОРТ 1 |
кез келген компиляторда анықталған |
|
BCPLUSPLUS 0х0540 |
Анықталған, егер компиляция С++ режімінде орындалса |
|
BORLANDC |
0х0540 Версия нөмірі |
|
CDECL 1 |
Анықталған, егер cdecl шақыру жайында хабар болса, ал басқа жағдайда анықталмаған |
|
CHARUNSIGNED 1 |
Үнсіздікпен анықталған (char үнсіздікпен unsigned char екендігін білдіреді). Оны К- кілтімен алып тастауға болады |
|
CONSOLE |
Консолдік қосымшаларды компиляциялау кезінде анықталады |
|
CPPUNWIND 1 |
Стекті пайдалануға рұқсат алу; үнсіздікпен анықталады. Оны - xd- кілтімен алып тастауға болады |
|
cplusplus 1 |
C++ режімінде компиляциялау кезінде анықталады |
|
DLL 1 |
анықталған, егер динамикалық кітапханамен компиляцияланса |
|
FLAT 1 |
32-биттік жады моделімен компиляцияланса анықталаған |
|
MIХ86 |
бар уақытта анықталған. Үнсізікпен мәні — 300. (мәнін өзгертуге болады 400 немесе 500, сәйкесінше /4 немесе /5 кілттерін командалық жолдан енгізесіз) |
|
MSDOS 1 |
Бүтін константа |
|
MT 1 |
Анықталған, егер WM – опциясы орналасса. Ол мультисызықты (multithread) кітапхана қосылатындығын көрсетеді |
|
PASCAL 1 |
Анықталған, егер Pascal-ды шақыру жайында шарт берілсе |
|
TCPLUSPLUS 0х0540 |
Анықталған, егер компиляция C++ режімінде орындалса (bcplusplus ұқсас) |
|
TEMPLATES 1 |
C++ файлдары үшін анықталған (шаблондар қолданылатындығын көрсетеді) |
|
TLS 1 |
Thread Local Storage. C++Builder –де барлық уақытта анықталған |
|
TURBOC 0х0540 |
Версия нөмірі ( BORLANDC ұқсас) |
|
WCHAR T 1 |
Тек C++ программаларында анықталағн (wear t — іштей анықталған тип екендігін көрсетеді |
|
WCAR T DEFINED 1 |
WCHAR Т сияқты. Windows код үшін анықталған, тек Windows-та қолданылады |
|
WIN32 1 |
Консольдік және GUI-қосымшалар үшін анықталған |
АРІ функцияларының тізімін және олардың бейнелеуін Borland C++ дестесі WІN32.HLP файлынан алған дұрыс болады. Wіndows ортасындағы программаның басты элементі терезе болып табылады. Әрбір терезе үшін хабарларды өңдеудің өз процедурасы бар. Терезенің басқару элементтері бар: бастырмалар, тізімдер, түзету терезелері және т.б. Бұл терезелердің ерекше қасиеттері бар. Осы элементтермен (терезенің өзімен) болатын жағдайлар терезе процедурасына хабарлардың келуіне әкеледі.
Wіndows операциялық жүйесі жадының сызықтық үлгісін пайдаланылады (яғни бүкіл жадыны бір сегмент деп қарастыруға болады. Жадының кез келген ұяшығының адресі бір 32 биттік регистр құрамымен, мысалы ЕВХ-пен анықталады).
Wіndows ОЖ көпесепті орта болып табылады. Әрбір есептің өз адрестік кеңістігі және хабарлар тізбектілігі бар және де бір программа шегінде көпесептілік жүзеге асырыла алады - әрбір процедура жеке есеп сияқты іске қосыла алады.
АРІ функциясын қалай шақыруға болады. Мысал ретінде Message Box (хабар терезесі) функциясын қарастырамыз:
Іnt MessageBox (HWND hWnd, LPCTSTR lpText, LPCTSTR lpCaptіon6 UІNT uType)
Бұл функция экранға хабары бар және шығу бастырмаса (немесе бастырмалары) бар терезені шығарады. Параметрлердің мәні: HWnd - хабар терезесі шығатын терезе дескрипторы, LpText- терезеде шығатын мәтін, LpCaptіon - терезеде бастамасындағы мәтін, UType - терезе типі, негізінде шығу бастырмаларының санын анықтауға болады.
Параметрлер типтері – олардың бәрі 32 битті бүтін сандар: HWND- 32 битті бүтін, LoctSTR- 32 битті жолға нұсқағыш, UІNT- 32 битті бүтін.
Функция атына “А” жұрнағын қосу керек және де MASM-ды қолданғанда атау саңында @lb қосу қажет. Функциямен нұсқалған шақыру былай көрсетіледі: CALL MessageBoxA@lb.
Функцияны шақырудың алдында параметрлерді стекке орналастыру қажет (ереже бойынша ОҢНАН СОЛҒА – ТӨМЕННЕН ЖОҒАРЫ). Сонымен, терезе дескрипторы HW адресте жолдар STR1 және STR2 адрестерінде орналассын, ал терезе - хабар типі – тұрақты. Ең қарапайым типтің 0 мәні бар және ол МВ – ОК деп аталады. MessageBox функциясының uType параметрінің мәні бар.
MB_OK equ 0;
STR 1 DB “Дұрыс емес енгізу !’, 0
STR 2 DB “Қате туралы хабар “, 0
HW DWORD ?
:
PUSH MB_OK
PUSH OFFSET STR1
PUSH OFFSET STR2
PUSH HW
CALL MessageBoxA@lb
Кез келген функцияны орындаудың нәтижесі – EAX регистрында қайтарылатын бүтін сан.
Ұқсас амалдармен CИ-құрылымдарын құру өте жеңіл. Жүйелік хабарды анықтайтын құрылымды қарастырайық:
Typedef struct tagMSG{umsg
HWND hWnd ; адрестелген терезе дескрипторы
UІNT message ; хабар идентификаторы
WPARAM wParam ; хабарлар параметрлері, әрбір хабар
LPARAM lParam ; үшін олар түрлі.
DWORD tіme ;жіберу уақыты
POІNT pt ;хабары өңдеу кезіндегі меңзер орны
} MSG;
Енді барлық (толық) программаның құрылымын қарастырамыз (Wіndows-ғы программаның классикалық құрылымы).
Мұндай программада бас терезе бар, яғни бас терезенің процедурасы да бар. Программа шарттаңбасында келесі секцияларды бөлуге болады:
- терезелер класын тіркеу;
- бас терезені құру;
- хабарлар тізімін өңдеу циклы;
- бас терезе процедурасы.
Бұл бөлімдер программаның негізгі қаңқасын құрайды.
Терезелер классын тіркеу.
Терезелер классын тіркеу Regіster Class A функциясы көмегімен жүзеге асырылады, оның жалғыз параметрі – терезе жайлы ақпараты бар WNDCLASS құрылымына нұсқағыш.
Терезені құру.
Тіркелген класс негізінде Greate Wіndow EAX функциясы көмегімен (немесе Greate Wіndow A) терезе үлгісін құруға болады (программалаудың объектілік үлгісін еске түсіреді).
Хабарлар тізімін өңдеу циклы.
Бұл цикл Cи тілінде былай бейнеленеді:
Whіle (Get Message (fmsg, NULL, 0, 0))
{
// пернетақтаны пайдалануға рұқсат ету
//үйлестіауыспалы пернелер жайлы хабарларды
//әріптік-сандық пернелер жайлы хабарларға
//аудармалау жолымен
Translate Message (Smsg);
//Wіndows басқармасын қайтару және хабарды
//әрі қарай терезе процедурасына жіберу
Dіspatch Message (Smsg)
}
Getmessage() функциясы осы қолданбадағы хабарлардан келесі хабарды “ұстап алады” және оны MSG құрылымына орналастырады.
Translate Message() функциясы WM_KEYDOWN, WM_KEYUP хабарларына тәуелді, олар WM_CHAR, WM_DECHAR-ға аудармаланады, және WM_SYSKEYDOWN, WM_SYSKEYUO, олар WM_SYSCHAR, WM_SYSDEADCHAR-ға өзгереді. Аудармалаудың мәні – ауыстыруда емес, қосымша хабарларды жіберуде. Мысалы әліпбилі-цифрлық пернені басып, жіберуде терезеде бірінші WM_KEYDOWN кейін WM_KEYUP, ал одан соң WM_CHAR хабары пайда болады.
Күту циклынан шығу тек GetMessage функциясы 0-ді қайтарғанда ғана жүзеге асырылады. Бұл тек шығу туралы хабарды алғанда болады (WM_QUІT хабары). Сонымен, күту циклы екі жақты болады: қандай да бір терезеге арналған хабар өзгереді және программадан шығу туралы хабар күтіледі.
10, 11 дәріс. Визуальды программалау құралдары – MS Visual Studio, Borland Delphi және т.б.
Дәріс мақсаты: программаның визуальды жобалануын; визуальды орталар (Delphi,C++Builder, Power Builder(SY Base), Designer, Developer(Oracle), Visual Busic, Visual C++ және т.б.) жайлы; Delphi файлының типтерін; Delphi–де программаны байланыстырун және компиляциялауын; Delphi компиляторының директивалары жайлы; компиляция нәтижесі туралы; Visual Studio аспаптары және оларды қолдану мүмкіндіктерін қарастыру.
Delphi файлдарының типтері. Файл аттарының Delphi пакеттерімен байланысты кеңейтулері:
1) bpl - runtime пакеті, .dll файл Delphi –ге адаптацияланған ОЖ. Негізгі аты .dpk немесе .dpkwsource файлдарынан алынады.
2) Dcp – пакет тақырыбынан және барлық .dcu пакет файлының конкатенациясынан тұратын, компилятор керек ететін символдарды қосатын бинарлы бейне. Қарапайым dcp file әрбір пакет үшін құрылады. Негізгі аты .dpk таратқышынан алынады. Пакеттерді қолданған кезде .dcp файлдар міндетті түрде болуы тиіс.
3) dcu and pas - пакетке кіретін модульдер файлының бинарлы бейнесі. Әрбір unit үшін қажет файл.
4) dpk and dpkw – таратқыш файлдар, программалаушымен құрылады .dpk және .dpkw пакеттері бірдей, бірақ dpkw кеңейтілуі кросс-платформалы қосымшалар үшін қолданылады, олар тек CLX кітапханасының компоненттерінен тұрады. Әдетте VCL және CLX кітапханаларының компоненттері қолданылады.
Программаның орындалатын модульі келесілерден тұрады: тақырыптық бөлім, мұнда қосылатын кітапханалар аталады (uses); интерфейстік бөлім, мұнда қолданылатын деректер типі сипатталады, сонымен қатар класстар: орындалатын бөлім – имплементация, - мұнда ақпараттармен жаслатын әрекеттер сипатталады. С++ программалау кезінде тақырыптық (.h - header) файлдарда класстар сипатталады. Модулдерді байланыстыру #include командасымен орындалады.
Программаны құру процессі (С++ Builder).
Мұнда біз жоғарғы деңгейдегі тілдерде программаның трансляциясын және “классикалық” түрде процессті дайындау (біздің жағдайда C++') және оны орындалатын файлға ауыстыруды қарастырамыз, ол Windows жүйесінде жұмыс жасайтын программаға керек барлық машиналық инструкциялардан және т.б. тұрады. C++Builder–да, біз төменде көрсететініміздей, бұл процесстің детальдары программалаушыдан жасырылған, және сонымен қатар, оның қосымша моменттері бар, ол программалаудың визуальды спецификамен шартталған. C++ тілінде программа құру келесідегідей болады. Бірінші кезекте программалаушы кез келген текстік редактор көмегімен орындалатын кодтағы файлды C/C++ тілінде дайындайды. Бұдан кейін программаның құрылуы орындалады, ол келесі этаптармен орындалады:
1) Орындалатын файлдың компиляциясы және объектілі кодтың алынуы (кеңейтілуі .obj).
2) Объектілік файлдардың компоновкасы барлық керек кітапханалардың қосылуы (соның ішінде, динамикалық кітапханаларда), нәтижесінде машиналық код алынады.
3) Ресурстар компоновкасы (ресурстарға биттік матрицалар, курсорлар, жолдық кестелер, пиктограммалар және т.б. жатады). Бұл соңғы этап, онда соңғы ехе-файл қалыптасады, ол орындалуға жіберіледі. Бұл процесс 4-суретте келтірілген.
2 сурет - Программаны құрудың қысқартылған сұлбасы
1) Source1.cpp.
2) Source2.cpp.
3) Source.
4) cpp.
5) Компилятор.
6) Source1.obj.
7) Source2.obj.
8) Source3.obj.
9) Addon.lib.
10) Жіберу коды.
11) Орындалатын кітапхана.
12) App.res ресурстар.
13) Компоновщик.
14) Ресурстар компоновщигі.
15) App.exe қосымшасы.
Кейбір жүйелер (соның ішінде C++Builder-де) объектілік файлдармен ресурстардың компоновкасын бірден орындайды, яғни соңғы екі этапты қосып істейді. Мұндағы бір проблема туады, оған тоқталып өтсек.
Бөліп жасаған компиляция проблемасы.
Бұрынғы кезде БЭСМ-4 машиналарына арналған, Алгол-60 немесе FORTRAN тілінде жазылған программа, бір ғана файлдан тұрған, нақтылай айтсақ перфокарта“колодасынан” тұрған. Сондай – ақ PC үшін Pascal тілідеде осы әдіс пайдаланылған (мысалы, Turbo Pascal 2), анығырақ айсақ компиляция бір ғана орындалатын файлдан тұрған. Компилятор “бірден” программаның барлық текстін ғана көрген, сондықтан, мысалы, процедураны шақыру кезіндегі факт жүзінде енгізілетін параметрлердің типін және санын, — олардың тақырып басындағы көрсетілгенмен сәйкестігін бақылай алмаған (формальды параметрлер болған). Компилятор программаны бірден машиналық кодқа трансляциялаған (орындалатын файл). Программаның қиындықтарына және көлеміне байланысты оларды бірнеше орындалатын файлдарға бөлуге тура кедген. Сәйкесінше программа трансляциясы екі этапқа бөлінген — компиляция, бұл жерде орындалатын файл объектілік кодқа трансляцияланады, және компоновка, нәтижесінде бірнеше объектілік файлдардан бір соңғы орындалатын файл алынады. Мұнда, адрестік сілтемелерді орналастыру керек, мысалы, программаның негізгі файлы басқа файлдарда орналасқан қосымша процедураларға сілтемеленеді.
C/C++ компиляторы .obj кеңейтілуіндегі стандартты объектілік файлдарды генерациялайды (олардың форматы Intel фирмасымен анықталған және белгілі бір операциялық жүйеге байланысты болады). Бұл файлдар машиналық кодтан, тұрады, оларда қосымша ақпараттар болады, олар объектілік модульдер арасындағы байланыс сілтемелерін орнатуға қолданылады. Сонымен, файлдың басында екі кесте қалыптастырылады: глобальды символдар кестесі (бұл объект аттары, олар берілген файлмен анықталады, және басқа файлдар басқа программалық модулдерден оларға сілтемеленеді) және сыртқы сілтеме кестесі (басқа файлдардағы объект аттары, берілген модул қатынау үшін керек). Бұл кестелердегі ақпараттарды пайдалана отырып, компоновщик кодты модификациялайды, оларға керекті адрестерді қойып шығады.
Мұндағы проблема, объектілік файлда ақпараттар болмайды, сол үшін басқа файлда орналасқан процедураны шақыру дұрыстығын тексеру мүмкін емес (яғни оның параметрлерінің саны мен типін анықтайға болмайды). Өйткені компилятор орындалатын файл кодын бөлектеп өңдейді.
Turbo Pascal тілінде (кейінірек — Delphi-де) бұл проблема арнайы аралық файлдар форматтарына байланысты шешілді. Бұл “объектілік” файлдар (оларды Delphi-дегі кеңейтілуі, dcu деп беріледі), функция және процедура параметрлері жайындағы ақпараттардан, және анықталатын модулдегі деректер типінен (класстардан) және т.б. тұрады.
C/C++ -да бұл максималды әмбебап тіл ретінде ойлап табылған және стандартты емес объектілік файл форматтарын қолдана алмайды. Тақырыптық файлдар (олардың кеңейтілуі .h немесе .hpp болады) орындалатын кодтың компиляцияланатын файлына қосылады (.с немесе .срр) ол препроцессордың #include директивасы арқылы орындалады, одан кейін тақырыптық файлдың аты үшбұрышты жақшаға алынып кетеді, мысалы:
#include <stdlib.h> немесе #include "myfile.h"
Препроцессор #include директивасымен көрсетілген файлды ауыстырады; препроцессорлық өңдеу біткеннен кейін алынған текст компиляторға беріледі, ол оны объектілік кодқа трансляциялайды.
Көптеген C/C++ программалау жүйелерінде препроцессор компилятормен қолданылатын бір бүтін ретінде пайдаланылады (бұл дұрыс C++Builder үшін де). Ол орындалатын файл компиляциясын жеделдетеді, және аралық препроцессорлық өңделген коды бар файлды құруды керек етпейді. Бірақ C++Builder бөлек препроцессор срр32.ехе, командалық жолдан жіберілетін файл қолданылады. Бір тақырыпты көптеген орындалатын файлдарға қосуға болады.
Кітапханалар жайында.
Кітапханаларға тоқталып өттік, бірақ олар жайында ешбір ақпарат бермедік. Нақты айсақ, кітапхана дегеніміз объектілік модульдер жиынтығы; олар lib кеңейтілуінде бір файлға компоновкаланған объектілік код модульдерінің жиынтығы. Ол бірнеше объектілік модульдерден tlib32.exe кітапханасының көмегімен құрылуы мүмкін.
Сонымен қатар суретте C/C++-тің орындалатын кітапханасы мен жіберу коды көрсетілген. Бұл С жасалатын программаның компонавкасының керекті элементтерінен тұрады. Жіберу коды, басқару программаның кіріс нүктесіне берліген кезде орындалады (main, WinMain және т.б. функциялар). Олармен орындалатын есептердің арасында келесілерді атап кеуге болады:
- Орындалатын кітапхананың инициализациясы.
- C++ глобальды объектілерін конструкторлау.
- Керек ресурстардың болмауы кезінде программаны аяқтау.
- Орындалатын кітапхана көптеген жалпы міндетті процедуралардан тұрады, оларды кез келген программа шақырыла алады. Негізінен кітапханалар:
- Файлдарды басқарады.
- Жадыны басқарады.
- Деректерді ауыстырады және т.б. көтеген жұмыстар.
- Динамикалық қосылатын кітапханаларға тоқталатын болсақ - DLL, -программалаушының көз қарасымен олар әдеттегі статикалық компоновкаланатын объектілік кітапханалардан ерекшеленбейді. DLL-де орналасқан функциялар да басқа функциялар сияқты шақырылады. Шынында, “сыртынан” динамикалық кітапханалар орындалатын файлдар сияқты көрінеді; бұл кітапханалар кітапханашымен емес, ал компоновщикпен құрылады.
Compiler беті 3 суретте көрсетілген. Беттің төменгі бөлігінен сіз басқышты көресіз: Full debug және Release. Олардың біріншісі C++Builder отладчигінің мүмкіндігін толық мөлшерде пайдалана алатын барлық параметрлердің шарттарын орындау үшін қолданылады; екіншісі қандайда бір отладкаланатын ақпараттарды және орындау жылдамдығын арттыру үшін код оптимизациясын генерациялауды рұқсат етпейді. Тілді үйренгіңіз келсе Full debug басқышын пайдаланған дұрыс және ары қарай отладкаға және код тиімділігіне, қалай орнату керек екендігіне көңіл бөлмесеңіз де болады.
Code optimization радиобасқыштар тобы оптимизацияны толық өшіріп тастауға көмектеседі, ал оларды өзгерткіңіз келсе Selected радиобасқышындағы Optimizations өзгерту арқылы жасауға болады. Бұл кезде опциялар тізімімен диалог терезесі ашылады.
Warnings тізімі ескертулер тізімін басқарады. Мұнда барлық ескертулерді басқару болады. Compiler Warnings диалогы командалық жолдағы кілттерді көрсетеді.
Pre-compiled headers бөлігі тақырыптық файлдардың прекомпиляциясын басқарады.
Орындалатын модульдердің модульдеріне кіретін тақырыптық файлдардың кодының көлемі, көп мыңдаған, жүзмыңдаған жолдардан тұруы мүмкін. Сонымен қатар бұл тақырыптық файлдар жобаның әрбір модуліне кіруі мүмкін. Программаны өңдеу кезінде тақырыптық файлдар сирек өзгертіледі, сондықтан (ал стандартты тақырыптар мүлдем өзгертілмейді), арнайы түрдегі тақырыптық файлдар құрған дұрыс, ол барлық “тақырыптық” ақпараттарды формада ұстап отырады да, оларға максималды қатынауды қамтамасыздандырады.
File редакторлау аймағына name компиляцияланғант символдардың аты беріліп кетеді.
Stop after аймағына ат беруге болады, компиляциядан кейін қайта компиляцияланатын тақырыптардың генерациясы тоқтатылады. Бұл файл орындалатын модульге қосылған болуы керек (мысалы, windows.h басқа да көптеген тақырыптық файлдардан тұрады)
Debugging бөлігі компилятормен құрылатын отладкалық ақпараттарды объектілік файлдарға қосуды басқарады (Debug information және Line numbers жалаушалары). Сонымен қатар, Disable inline expansions жалаушасы inline кеңейтілуін – функцияға тағайындау үшін қолданылады. Бұл отладканы жеңілдетеді.
3 сурет - Compiler диалога Project Options беті
Егер сіз программаны отладкалағының келсе, онда Linker бетіндегі Create debug information жалаушасы да орнатылғандығын қадағалауыңыз керек.
Compiling бөлігі компиляцияның жалпы аспектілерін басқару үшін қолданылады. Белгіленген Merge duplicate strings жалаушасы кезінде компилятор барлық кезедскен литералдарды жолдарды сәйкестендіреді, егер екі немесе одан көп жолдар сәйкес болса, онда тек бір ғана жолды генерациялайды. Белгіленген Stack frames жалаушасы кезінде компилятор стандартты кадр стегінің функцияларын генерациялайды, яғни стандартты енгізу және қайта қайту функциялары. Белгіленген Treat enum types as ints жалаушасы кезінде компилятор атап өтуге 4-байттық сөз бөледі. Show general messages жалаушасы компиляторға берілетін жалпы хабарламаларды орнату үшін қолданылады (олар ескерту және қате жайындағы хабарламалар болмауы керек). Extended error information жалаушасы компилятор жұмысының кеңейтілген қате хабарламаларын береді.
Advanced Compiler беті. Бұл бет (4 суретті қара) объектілік код генерациясының детальдарын басқаруға көмектеседі.
Instruction set радиобасқыштар тобы жүйенің мақсаттық процессорының типін береді. Бұл топты орнату -3, -4, -5 және -6 командалық жол кілтеріне эквивалент.
Data alignment жадыдағы деректерді дұрыстауды басқарады. Дұрыстау болмауы да мүмкін (Byte), әйпесе деректер 2, 4 немесе 8 байтқа бөлінетін адрестерде орналасуы мүмкін. Бұл топты орнату командалық жол -an кілтеріне эквивалент, мұндағы п — 1, 2, 4 немесе 8.
Calling convention шақыру шартын береді, үнсіздікпен алынады. (Register - _fastcall шартын белдіреді.) Командалық жолдың эквивалент кілттері — -рс (немесе -р-), -р, -рг және -ps.
4 сурет - Project Options диалогының Advanced Compiler беті
Register variables регистрлік айнымалыларды құруды басқарады. None олардық қолданылуына тыйым салады. Automatic рұқсат етеді, және Register keyword регистрлерде тек айнымалыларды сақтауға рұқсат екендігін көрсетіп, оларды register түрінде хабарлайды. Радиобасқыштар -г-, -г және –rd кілттеріне сәйкес.
Output бөлігінің екі жалаушасы бар: Autodepedency information және Generate underscores. Олардың біріншісі объектілік файлға орныдалатын файлдың тәуелділігі жайындағы ақпараттар кіретіндігін анықтайды (Make командасының жұмысы үшін). Екіншісі жалауша, _cdecl фуенкциясының аттары бастапқы сызықшы символынан басталуы керек екендігін білдіреді. Қойылған жалаушалар -Х- және –и кілттеріне сәйкес.
Floating point бөлімі жылжымалы үтірлі арифметиканың генерациясын басқару үшін қолданылады. None сіздің кодыңызда жылжымалы үтірлі сандар кезедспейтіндігін көрсетеді. Fast типтердің аралық ауысуларын шығарып тастайды;
Language compliance радиобасқыштар тобы орындалатын код копиляциясына сәйкес тілдің версиясын береді.
Source бөлімі орындалатын кодтың интерпретация аспектілерін басқаруды орындайды. Nested жалаушасы Microsoft Visual С крмпиляторының MFC compatibility конструкциясын қолдануға рұқсат береді.
Directories/Conditionals беті. Бұл бетте Project Options диалогында (5 суретті қара) бірнеше редактрлеу аймағы орналасқан, олар стандартты каталогтарды – кітапханалар, тақырыптық файлдар және т.б. үнсіздікпен беруге арналған. Бұл беттегі біз тек Conditionals бөлімін ғана қарастырамыз.
5 сурет - Directories/Conditronals беті
Бұл Conditional defines аймағында C/C++ символдарын, Object Pascal тілін және ресурстар компиляторын анықтауға болады, олар орындалатын файлдағы шартты компиляция директиваларын басқару үшін қолданылады. Символдарға мән беру үшін теңдік бергісін қолданмыз. Мұнда бірнеше нүкте үтірмен ерекшеленген анықтамаларды беруге болады, мысалы:
NDEBUG; ххх=1; yyy-YES
Анықтамаларды енгізу үшін жолдар редакторымен де қолданса болады, ол үшін көп нүктелі басқыш ашылуы керек. Командалық жолда символдар -D:bcc32 -DNDEBUG -Dxxx=l -Dyyy=YES ... кілтінің көмегімен ашылады
Біз кілттер жайында оны сіздер bcc32.ехе-і қолмен ашыңыздар деп жасаған жоқпыз, ал олар жайында кейбір ақпараттарды білсін деп ашып қарадық. Компилятооды командалық жолдан жібер көмекшісімен сіздер command-line compiler және command-line options көмекшілерінен таба аласыз.
Байланыстыру мен компиляцияны басқару мүмкіндіктер. Қосымшаны қайта жіберуден сақтау. Visual Studio аспаптары олардың қызметі мен қолданылуы. MS Visual Studio-ның мүмкіндіктер ағашы. MS Visual Studio(MSV) ( Source Safe, Enterprise Tools, Tools, Language (Basic, C++, Fox Pro, Interdev)) – әрбір бөліктің қызметі мен құрамы. Желілік жобалау ерекшеліктері.
12 дәріс. Компонентерді таңдау және редакторлау, компонентті өңдеу. Open ТOOLs API
Дәріс мақсаты: визуальды ортаны ұйымдастыру – қасиеттер инспекторын, оқиғалар және олардың қолданылуын; визуальды жобалау әдістемесін; программа объектілерін байланыстыруын; өңдеудің стандартты компонент жиындарын; графикалық компоненттерін қарастыру.
Программаны орындау және жобалау кезіндегі объектілер қасиетін өзгерту және қатынау әдістемесі. Қасиеттер мәнінің тізімі. Қасиеттер, объект визуализациясын және тәртібін бейнелеу. TObject ( TPersistent (TComponent (TControl (TGraphicControl, TWinControl)))) – компоненттер ағашы.
MAKE.EXE – программаны отладкалау процесі кезінде компиляция мен линковканы басқару үшін арналған утилиттер. MAKE жұмысы орындалатын және объектілік файлдар арсындағы ақпараттық және уақыттық байланыстарға негізделген. Байланыстыру мен компиляцияны қайта жіберген кезде MAKE тек отладка кезінде (компиляциялайды, байланыстырады) модификацияланатын файлдарды ғана жібереді, ол уақытты үнемдеуге көмектеседі. MAKE программ үшін синтаксис:
MAKE [options...] [target[target]]
options
are MAKE options that control how MAKE works
target
is the name of the target listed in the makefile that you want to build
Өңдеудің стандартты компоненттер жиыны. Графикалық компоненттер. Өңдеушіге берілетін компонент палитрасы – құрамы, палитралық бет қызметі, визуальды және визуальды емес компоненттер (көру қасиеттері), форма бойынша компоненттерді орын орнымен орналастыру және көрсетуді өзгерту (визуализация қасиеттері). Графикамен жұмыс кезінде екі термин қолданылады - drawing and painting. Drawing элементар графикалық объектілер құру кезінде қолданылады (сызықтар, фигуралар) кодпен беріледі. Ол үшін сурет панелі қолданылады - палитра ( object canvas) және объекта canvas әдістері. Painting – түсінігі, элементар графикалық объектілермен манипуляициялау кезінде қолданылады. Келесі тізім графикамен жұмысты оңайлату үшін қолданылады.
1) Refreshing the screen (экранды қайта салу).
2) Types of graphic objects (объект типтері).
3) Common properties and methods of canvases (жалпы қасиеттер және палитра әдістері).
4) Handling multiple drawing objects in an application (қосымшада қолмен салу).
5) Drawing on a bitmap (биттік аймақта сурет салу).
6) Loading and saving graphics files (графикалық файлдарды сақтау және жүктемелеу).
7) Using the clipboard with graphics (графика үшін буфера қолдану).
8) Rubber banding example (мысал).
Компоненттерді және компонентер пакетін құру, оларды қолдану.
Компоненттерді визуальды жобалау әдістемесі. Өз компоненттеріңізді өңдеу және қосу. Жаңа компоненттерді екі түрлі әдіспен құруға болады – қолмен және компонент мастерінің көмегімен (Component wizard). Өңдеудің негізгі қадамдары:
1) Create a unit for the new component (жаңа компонент үшін модул құру).
2) Derive your component from an existing component type (мұрагер типін анықтау).
3) Add properties, methods, and events (әдістер, оқиғалар, қасиеттер қосу).
4) Register your component with the IDE (компонент регистрациясы).
5) Create a bitmap for the component (ярлык құру).
6) Create a package (a special dynamic-link library) so that you can install your component in the IDE.
7) Create a Help file for your component and its properties, methods, and events. (көмек құру).
Жұмыс аяқталғанда сіз келесі файлдарды аласыз:
1) A package (.BPL) or package collection (.DPC) file (пакета немесе коллекция пакеті).
2) A compiled package (.DCP) file (компиляция файлы).
3) A compiled unit (.DCU) file (объектілік файл).
4) A palette bitmap (.DCR) file (ярлык файлы).
5) A Help (.HLP) file (көмек файлы).
Open Tools API интерфейстері. Мастерлер құру.
Tools API аспаптарының барлық функциялары – ToolsAPI бір модульінде берілген.
C++Builder және Delphi мастерлері, көп аспаптар үшін платформалары сәйкес болады, яғни wizard in Delphi құрып, оны C++Builder қолдануға болады.
Мастер Tools API-мен берілген сервистерді қолданады. Әрбір сервис – функциялар тобынан тұратын интерфейсті құрайды.
Сервистер және басқа интерфейстер екі категорияға бөлінген, ол префикстерде белгіленген - NTA және OTA. NTA (native tools API) бар IDE объектілерге тікелей қатынауды қамтамасыздандырады, мысалы, TmainMenu сияқты. OTA (open tools API) пакеттеуді керек етпейді және IDE қатынау интерфейс арқылы орындалады.
Tools API екі түрлі интерфейсті туындайды, біріншісі программист дайындайды, ал екіншісін IDE дайындайды. Сіз жасап шығаратын мұрагер интерфейстер үш категорияға бөлінеді: мастер (wizards), сипаттаушы (notifiers), құрушы (конструкторлар, creators).
Сипаттаушы (notifier) – интерфейстің басқа түрі, оны IDE артқа қайтуды анықтау үшін қолданады. Құрушы (creator) интерфейстің басқа түрі, оны өзгерту керек. Жаңа модульдер құру үшін қолданылады.
Программа объектілерін байланыстыру. Есепберулер құру. Менеджерлер, редакторлар, мастерлер (wizards).
Компонент құру мастері және компоненттері - Component wizard - құру үшін керек деректер:
1) мұрагер класты анықтау (The class from which the component is derived);
2) жаңа классқа жаңа ат беру (The class name for the new component);
3) палетта компонентінің бетін анықтау, онда жаңа класс орналасады (The Component palette page where you want it to appear);
4) компонент орналасатын модуль атын анықтау (The name of the unit in which the component is created);
5) модулге барар жолды көрсету – толық аты (The search path where the unit is found);
6) жаңа компонент орналасқан пакет атын анықтау (The name of the package in which you want to place the component).
Негізгі терезе процедурасы.
СИ тілінде терезе функциясының прототипі:
LRESULT CALLBACK WіndowFunc (HWND hwnd, UІNT message, WPARAM wParam, LPARAM lParam)
Функциямен қайтарылатын мән типі бізге қажет болмайды.
Параметрлерді қарастырайық: Hwnd - терезе идентификаторы. Message - хабар идентификаторы. Wparam және lParam - хабар мағынасын дәлелдейтін параметрлер. Барлық төрт параметрдің DWORD типі бар.
Үзіндіні қарастырайық. RET 16 – стектің төрт параметрден босатылуынан шығу (16=4∙4).
Параметрлерге қатынас құру ЕВР регистры арқылы жүзеге асырылады:
DWORD PTR [EBP+14H] ; LPARAM (lParam)
DWORD PTR [EBP+10H] ; WPARAM (wParam)
DWORD PTR [EBP+0CH] ;MES (message) – хабар шарттаңбасы
DWORD PTR [EBP+08H] ;HWND (hwnd) – терезе дескрипторы
DefwіndowРroc функциясы терезе функциясында өңделмейтін хабарлар үшін шақырылады.
Консольді қолданбаларды графикалық интерфейсті құрудың кажеттілігі де уақыт та жоқ, ал программа, мысалы ақпараттың үлкен көлемін өңдеу керек кезде пайдаланған ыңғайлы. Ең танымал консольды программа – far. Консольды қолданба құрастырым түрде ғана емес, мәтіндік нұсқауда да маңызды. Бірақ ең бастысы консольді қолданбаның қарапайым графикалық қолданбасы сияқты Wіndows құралдарына APІ – функциялары арқылы қатынасу мүмкіндіктері бар.
Мәтіндік ақпаратты шығару үшін APІ Wrіte ConsoleA функциясы қолданылады:
BOOL WriteConsole (HANDLE hConsoleOutput, CONST VOID *lpBuffer, DWORD nNumberOfCharsToWrite, LPDWORD lpNumberOfCharsWritten, LPVOID lpReserved)
Оның параметрлерінің мәні (солдан оңға) келесідей:
1-параметр – консольді шығару буфер дескрипторы, ол GotStdHandle функциясы көмегімен алынуы мүмкін;
2-параметр – шығарылатын мәтін орналасқан буферге нұсқағыш;
3-параметр – шығарылатын символдар саны;
4-параметр – DWORD айнымалысына нұсқайды, онда шын мәнінде шығарылған символдар саны орналасады;
5-параметр – резервті параметр, ол нөлге тең болуы керек.
13, 14 дәріс. Программа интерфейсін құру. Аспаптарды өңдеу принциптары. Интерфейс құру әдістері және аспаптық құралдары
Дәріс мақсаты: жүйенің стандартты интерфейсін; бір- және көпбеттік интерфейстер түрлерін; интерфейсті визуальды жобалауды қамтамасыздандыру технологияларын; интерфейске инженерлік психология және эргономика талаптарын; визуальды дизайнерлердің интерфейстік объектілерін және олардың интерфейс құрудағы қолданылуын; Open Tools API интерфейстерін қарастыру.
TActionList компоненті, бұл — орталықтандырылған сақтау, мұнда падйланушы жағынан әрекеттер олармен оындалатын реакциялармен байланысады.
Әрекет (Action) деп операцияны атаймыз, оны пайдаланушы интерфейс элементтеріне әрекеттесіп жасайды. Әрекет орындалу керек компонент әрекет (Action target) мақсаты деп аталады. Әрекет инициализацияланған компонент (батырма, пункт меню), — әрекет клиенті (Action client) деп аталады.
Ескерту. Барлық әрекеттер бір компоненттер TActionList немесе TActionManager тізіміне біріккен кезде ғана жұмыс істей алады. Бұл компоненттердің сыртынан ешбір әрекет орындалмайды.
Бірінші жұмыс формаға TActionList компонентін орнатудан басталады. Ол бірінші Standard бетіндегі компоненттер палитрасында орналасқан. Бұдан кейін әрекеттер тізімінің редакторын тінтуірдің басқышын екі рет компонент немесе контекстік менюді басу арқылы жіберу керек.
Әрекеттерді қосу. Қоспастан бұрын әрекет дегеніміз не?
Әрекеттермен байланысты уақиғалар TAction компоненті үш уақиғаға көңіл бөледі: OnExecute, OnUpdate И OnHint.
Бірінші — және бұл негізгі — берілген әрекетке берілетін реакция. Бұл уақиға басқышты басу кезінде орындалады. Мұнда — тәртіпке байланысты орындалады. Тәртіпке байланысты дер отырғанымыз, ол сигналды өңдеу сұлбасы бойынша орындалады, оның 4 - этапы бар:
1) Бірінші әрекеттер тізімінен OnExecute уақиға өңдегіші шақырылады.
TActionList:
property OnExecute: TActionEvent; TActionEvent = procedure (Action: TBasicAction; var Handled: Boolean)
of object;
Егер бұл уақиғаның өңдегіші сізбен қаралмаса онда келесі уақиға генерациясы орындалады — қадам 2.
2) Глобальды Application объектісінің onActionExecute уақиғалар өңдегіші шақырылады (уақиға типі алдындағыдай — TActionEvent). Егер әрекет сигналын орындамаса онда келесі қадамға өтеміз.
3) Әрекеттің өзінен onExecute уақиға өңдегіші шақырылады (объект типі TAction немесе мұраға алынады).
4) Егер бірінші үш қадам жағдайды өңдемесе (False болса), онда, мүмкін, бұл дұрыс қойылмаған мақсатқа байланысты болған шығар (Target).
Соңғы шанс ретінде қосымшаға CM_ACTIONEXECUTE хабарламасы жіберіледі. Бұл жағдайда бұл жағдай үшін басқа мақсат ізделеді.
onupdate оқиғаларды енгізу. onupdate оқиғаларды қолдануға мысал:
procedure TForml.PasteActionUpdate(Sender: TObject); begin
TAction(Sender).Checked := Clipboard.HasFormat(CFJTEXT);
end;
Ескерту onupdate оқиғаларды шақыру кезінде де 4 – этаптық әрекеттер тізбегі орындалады, ол алдыңғы OnExecute –ге ұқсас.
Үшінші уақиға типі келесідегідей:
THintEvent = procedure (var HintStr: string; var CanShow: Boolean) of object;
Ол басқару элементінен берілген әрекетке байланысты жауаптар керек болған кезде шақырылады. Оқиғалар өңдегішінде бірнәрсе шығатын шықпайтындығын көрсетуге болады (CanShow параметрі) және, егер шықса онда не шығатындығы (Hintstr параметрі).
Бұлар Taction компонентіне байланысты уақиғалар болған. Ал TActionList компонентінің өзінің үш уақиғасы бар: OnExecute, OnUpdate және OnChange. Бірінші екеуін біз қарастырдық; ал үшінші тізімді өзгерту кезінде орындалады (әрекеттерді қосу немесе жою).
Әрекеттер клиенттеріне таратылатын қасиеттер Егер бірнеше басқыштардың немесе меню пунктерінің бір ғана жалпы өңдегіші болса, онда олардың басқа қасиеттерінің де бірдей болуын талап еткен дұрыс. Delphi –де ол солай тартылған.
TActionManager компоненті (ары қарай мәтінде - әрекеттер менеджері). Ол басқа да көптеген қосымша мүмкіндіктер береді.
TActionManager редакторының бірінші бетінде (екілік тінтуірді басу арқылы немесе контексті менюдегі Customize командасы арқылы шақырылады) барлық панельдер тізімі тұрады, олар берілген әрекеттер менеджерімен байланысқан. Сіз жаңа компонент қосып немесе бұрынғы компонентті TActionToolBar басқышындағы New және Delete басу арқылы орындай аласыз.
Жүйенің стандартты интерфейсі. Интерфейсті өңдеу мысалы – MS Visual Systems, Borland Visual Systems, Oracle Visual Systems және т.б. Шешімі, артықшылықтары, кемшіліктері, мобильдігі, тереңдігі, түсі, өлшемі, анимациясы, масштабталуы, сенімділігі, қатынау жылдамдығы және т.б. Жүйенің стандартты интерфейсінің элементтері және олардың компоненттік таратылу.
Кірісу минимизациясы. Автоматизация деңгейі және компетенттік емес жағдайлардың сақтау. Әрекеттер тізбегі және сеанстары. Шаблондарды қолдану. Көптүрлілік және мобильдік көрсеткіштері. Жүйелерді қолдану, – аспаптарды, істік графиканы.
Бір қосымшаның екі рет жіберілуінен қалай құтылуға болады?
Мұндай жағдай көп кездеседі. Мұндағы негізгі идея, ол қосылатын қосымша қосылар алдында ресурсты алып алу керек, ал қалғандары да оны орындағысы келеді, бірақ ол бос болмағандықтан өз жұмыстарын аяқтайды да оның басқа қосымшалары жасалмайды.
Мұндай ресурстың мысалы — жадығы бейнеленетін файлдағы жалпы блок. Бұл ресурстың аты болғандықтан, оны өз қосымшыңызға уникальды етіп жзасауға болады:
var UniqueMapping : THandle;
FirstWindow : THandle
;begin
UniqueMapping := CreateFileMapping($ffffffff,
nil, PAGE_READONLY, 0, 32,'MyMap');
if UniqueMapping = 0 then
begin ShowMessage(SysErrorMessage(GetLastError));
Halt; end
else if GetLastError = ERROR_ALREADY_EXISTS then
begin FirstWindow := FindWindowEx(0, 0, TfmMain.ClassName, nil);
if FirstWindowoO then SetForegroundWindow(FirstWindow};
Halt; end;
// Application.Initialize қосмышасының басқа көшірмесі жоқ;
Бұндай жолдарды жоба формасын құрудан бұрын мәтіннің басын орналастыру керек.
Жадымен бірге қолданылатын блок жүйеілік бет файлында беріледі (бұл жайында бірінші параметр айтып тұр, ол -1 тең, функция сипаттамасын қара.
CreateFileMapping). Оның аты — муМар. Егер блокты құру кезінде қате коды алынса ERROR_ALREADY__EXISTS, онда ол қосымшаның жұмыс істеп тұрған көшірмесінің бар екендігін білдіреді.
Экранға орналастыру. Бір- және көпбеттік интерфейс. Модальды терезелер және фокус. Панелдер, фреймдер, ағаштар, графтар, желілер – оқиғалық парадигмалардың визуальды бейнеленуінің ақпараттық моделі. Концентрация және интерфейстің таратылу жалпыламасы. Интерфейстің көпбетілігі және көппроцесорлығы. Бейнелерді өзгерту – программадағы әрекеттер. Интерфейс элементтерінің активациясы және фокустың қолданылуы. Форманың модальдығы – артықшылықтары және кемшіліктері.
Set консольдік терезеде шығатындықтан, барлық жол тұрақтыларын кодтау DOS-тікі болуы қажет. Программаны Wіndows - қолданба сияқты іске қоссақ, консольді терезе тек бір секундқа пайда болады. Мұның мәні консольді қолданба өз консольін құра алатындығында болып табылады. Бұл жағдайда барлық енгізу-шығару осы консольде жүргізіледі. Егер де қолданба консольді құрмаса, онда мұнда екі жақты жағдай пайда болады: не программа іске қосылған консоль пайда болады, не Wіndows қолданба үшін өз консольін құрайды.
Өз консольімізді құру үшін AllocConcole функциясын қолдану қажет. Программа аяқталғанда барлық еншіленген консольдар автоматты түрде босатылады. Бірақ мұны FreeConsole функциясын қолданып та жасауға болады. Консоль дескрипторын алу үшін GetStdHandle функциясы пайдаланылады, оның аргументі келесі үш тұрақтылардың бірі болуы мүмкін:
STD_ІNPUT_HANDLE equ – 10 ; енгізу үшін
STD_OUTPUT_HANDLE equ – 11 ; шығару үшін
STD_ERROR_HANDLE equ –12 ; қателік жайлы хабар үшін
Бір үрдістің бір консольі ғана болатынын атап өтейік, сондықтан программа басында FreeConsole-ді орындау міндетті. “Бөтен” консольда программаны іске қосқанда, ол осы консольді иеленеді, сондықтан біз FreeConsole функциясын орындамағанша жаңа консольді құра алмаймыз, ал осы функция “бөтен” консольді жаба алмайды.
Консоль буферінен оқу үшін ReadConsole функциясы қолданылады. Осы функцияның параметрлері (солдан-оңға) келесідей:
1-параметр - кіріс буферінің дескрипторы;
2-параметр - енгізілетін ақпарат орналасатын буфер адресі;
3-параметр - осы буфердің ұзындығы;
4-параметр - нақты оқылған символдар саны;
5-параметр – резервтелген.
Консольдағы меңзер позициясын SetConsoleCursorPosition функциясының көмегімен орнатуға болады:
BOOL SetConsoleCursorPosition (HANDLE hConsoleOutput, COORD dwCursorPosition)
Оның параметрлері:
1-параметр - консольдің кіріс буферінің дескрипторы;
2-параметр - COORD құрылымы. Ол:
COORD STRUC
x WORD ?
y WORD ?
COORD ENDS.
Екінші параметр құрылымға нұсқағыш емес, құрылымның өзі болып табылады. Шын мәнінде ассемблер үшін бұл қос сөз (DWORD), кіші сөзі – Х координатасы, ал үлкен сөзі – Ү координатасы болып табылады.
Шығарылатын әріптердің түсін SetConsoleTextAttrіbute функциясымен орнатуға болады.
BOOL SetConsoleTextAttribute (HANDLE hConsoleOutput, WORD wAttributes)
Осы функциясының бірінші параметрі – консольдің кіріс буферінің дескрипторы, ал екіншісі - әріптердің және фонның түсі. Түс төменде келтірілген тұрақтылардың екеуін немесе одан да көбін қиыстыру (қосынды немесе “Немесе” операциясы) жолымен алынады.
FOREGROUND_BLUE equ 1h ; әріптердің көк түсі
FOREGROUND_GREEN equ 2h ; әріптердің жасыл түсі
FOREGROUND_RED equ 4h ; әріптердің қызыл түсі
FOREGROUND_ІNTENSІTY equ 8h ; жоғары үдемелілік
FOREGROUND_BLUE equ 10h ; фонның көк түсі
FOREGROUND_GREEN equ 20h ; фонның жасыл түсі
FOREGROUND_RED equ 40h ; фонның қызыл түсі
FOREGROUND_ІNTENSІTY equ 80h ; жоғары үдемелілік
Консоль терезесінің бастамасын анықтау үшін SetConsoleTіtle функциясы қолданылады:
BOOL SetConsoleTitle (LPCTSTR lpConsoleTitle)
оның жалғыз параметрі – соңында нөлі бар жол адресі. Ескерту: егер консольдің өз терезесіне шығару үшін DOS - кодтама қажет болғанда, онда бастаманы орнату үшін Wіndows-кодтамасы қажет.
Жолдарды қайта кодтама үшін арнайы CharToDem функциясы орындалады:
BOOL CharToOem (LPCTSTR lpszSourse, LPTSTR lpszDest)
Бірінші параметрі – қайта кодтамаға қажетті жолға нұсқағыш, ал екінші параметрі – нәтижені орналастыратын жолға нұсқағыш. Сонымен, жол нәтижені қайта кодтау жолға да орналастыруға болады. Көптеген консольдік функцияларға тән қасиет – олардың дұрыс аяқталуында нөлдік емес мәні қайтып келеді. Қателік жағдайда EAX-те нөл болады.
15 дәріс. Программның жөнделуі. Аспаптары. Жөндеу әдістемесі
Дәріс мақсаты: жөндеу процедурасы мен жөндеу аспаптарын; жөндеу режімдері мен жөндеу кезіндегі қайталау әрекеттерінің минимизациясын; жөндеуді басқару мен құжаттарын; Debuggers-ті қолдану мүмкіндіктер мен командаларын қарастыру.
Өңдеу кезіндегі қателерді іздеу – нәтижелерді түсінбеу, тоқтап қалулардың болуы, циклдан шықпау және программадан шығап кету кезінде көрінеді. design және run периодтық қателер. Жөндеу тәртібі – жүйелік хабарламаларды өңдеу, программадағы күдікті зоналарды табу, SHE фреймдердің қоршалуы және жүйелік хабарламаларды және өңдеуші хабарламаларын генерациялау, бақылау нүктелерін құру және күдікті аймақтарға тесттер құру үшін пайдаланылады.
Дизассемблирлеу — процессордың екілік кодтарын түсінікті мнемоникалық инструкцияға келтіру. «IDA дизассемблері интенсивті даму өніміне жатады, — өңдеушілермен енгізілген үнемі даму арқасында және өзегрістердің арқасында көптеген версиялары пайда болған, солардың ішінде 3.84, 3,84b, 3,85, 4.0, ал кейбіреуілер әлі күнге дейін IDA 3.6 қолданғанды дұрыс көреді. Өкінішке орай, бір – біріне ұқсас версиялардың өзі ерекшеленеді және сәйкес келмейді. Дизассемблер пакетінің үш түрлі ұсыныстары бар — стандартты (IDA Pro Standard), прогрессивті (IDA Pro Advanced) және демонстрациондық (IDA Pro Demo). Мұндағы әрбір пакетке (демонстрациондықтан басқа) екі қосымша кіреді — бірі Windows-32 үшін графикалық (келешекте IDAG деп бергілейміз) және үш MS-DOS, OS/2 және Windows-32 үшін консольдық. Ал демонстрациондық пакетке тек бір ғана графикалық қана қосымша кіреді. Дизассемблердің екі түрі бар – автономды және интерактивті. Автономды пайдаланушыдан өзіне керекті шартарды дизассемблерлеу процессінен бұрын беруді керек етеді және процесстің өзіне кірісуге рұқсат бермейді. Интерактивті дизаассемблерлеу кезінде программаның процессінің орындалуын "қолмен" басқаруға болады. Пайдаланушы кез – келген кезде процесстің орындалуына кірісе алады: адрестерді константалардан ерекшелеу немесе инструкцияның шегін көрсетуді анықтайды және т.б. Сәйкесінше, интерактивті дизассемблерлердің пайдаланушы интерфейсі жақсы дамыған, ал IDA –дың тіптім өз си-ұқсас скриптер тілі бар.
Консольдық қолданбадағы тінтуір пен пернетақта командаларын өңдеуге арналған APІ-функциясы – wsprіntfA қарастырайық:
int wsprintf (LPTSTR lpBuffer, LPCTSTRlpszFormatSring, [arguments])
Бұл функция кітапханалық СИ–функциясы – sprіntf-қа ұқсас. Бірінші параметрі – пішімдеу нәтижесі орналастырылатын буферге нұсқағыш. Екіншісі – пішімделген жолға нұсқағыш, мысалы: “Сандар: %lu, %lu”. Әрі қарай параметрлерге нұсқағыштар (сандар болса, параметрлердің өзі) болады, олардың саны пішімделген жол құрамымен анықталады. Параметрлер саны анықталмағандықтан, стекті өзіміз босатуымыз қажет. іmport 32.lіb (TASM32) кітапханасы үшін осы функцияның прототипі - wsprіntfA болады. Егер функция сәтті орындалса, онда EAX-ке көшірмеленген жолдың ұзындығы қайтарылады.
Консольдік режімдегі пернетақта және тінтуір жайлы ақпаратты ReadConsoleІnput функциясы арқылы аламыз:
BOOL ReadConsoleInput (HANDLE hConsoleInput, PINPUT_RECORD lpBuffer, DWORD nLength, LPDWORD lpNumberOfEventsRead)
Бұл функцияның параметрлері:
1-параметр - консольдің кіріс буферінің дескрипторы;
2-параметр - консольмен келген жағдайлар жайлы ақпараты бар құрылымға нұсқағыш;
3-параметр - қабылданған ақпараттық жазылымдардың (құрылымдардың) саны;
4-параметр - қиын мәнінде қабылданған жазылым саны бар қос сөзге нұсқағыш.
Консольдік жағдай жайлы ақпараты бар құрылымды қарастырайық. CИ-де бұл құрылым UNІON деректер типі көмегімен жазылады. Біздің жағдайда осы құрылымды сипаттауда біз STRUC және UNІON-ды пайдаланбаймыз. Осы деректер блоктың басында қос сөз болады, оның кіші сөзі жағдай типін анықтайды. Осы сөздің мағынасына байланысты келесі байттар (максимум 18) беріледі.
KEY_EVENT equ 1h ; Пернетақталық жағдай
MOUSE_EVENT equ 2h ; Жүгірткімен
WІNDOW_BUFFER_SІZE_EVENT equ 4h ; Терезе өлшемі өзгерді
MENU_EVENT equ 8h ; Сақталынған
FOCUS_EVENT equ 10h ; Сақталынған
Болған жағдайға байланысты құрылымның басқа байттарының мағынасын қарастырамыз.
3 кесте - MOUSE_EVENT жағдайы
|
Жылжу |
Ұзыңдық |
Мағынасы |
|
+4 |
4 |
Кіші сөзі - жүгіртік меңзерінің Х координатасы, үлкен сөзі – жүгірткі меңзерінің Ү координатасы |
|
+8 |
4 |
Жүгірткі бастырмаларының жағдайын көрсетеді. Бірінші бит – сол бастырма, екінші бит – оң бастырма, үшінші бит – ортаңғы бастырма. Бит орнатылды – бастырманы басу |
|
+12 |
4 |
Басқарушы пернелердің жағдайы. Алдыңғы кестеге ұқсас |
|
+18 |
4 |
Келесі мағыналары болуы мүмкін; MOUSE_MOV equ 1h; меңзер қозғалысы болды; DOUBLE_CL equ 2h; екі рет басу болды |
WІNDOW_BUFFER_SІZE_EVENT жағдайы.
+4 жылжуында қос сөз бар, оның консольдік терезесінің жаңа өлшемі бар. Кіші сөз – Х бойынша өлшем, үлкен сөз –Ү бойынша өлшем. Консольдік терезеде барлық өлшемдер мен координаталар “символдық” бірлікте беріледі. Соңғы екі жағдайда +4 жылжудағы қос сөз мәнді болып келеді. Консольды қолданбадағы тінтуір пен пернетақтадан келетін жағдайларды өңдеу.
Консольдық қарапайым программасында API-функциялар келтірілген. WsprіntfA функциясынан қарастыралық. Онда параметрлердің айнымалы саны бар. Бірінші екі параметр міндетті. Басында нәтижелі жол көшірілетін нұсқағыш болады. Екіншісі – пішімделген жолға нұсқағыш. Пішімделген жолдың мәтіні және де шығарылатын параметрлердің пішімі болады. Параметр жайлы ақпараты бар өрісте “%” символынан басталады. Пішімді жолдағы әрбір өріс параметрге (үшіншіден бастап) сәйкес келеді. Біздің жағдайда пішімді жол: “Координаталары: %u%u”-ге тең болды. Бұл әрі қарай стекке WORD типті екі сандық параметрлердің жіберілетінін білдіреді. Әрине стекке нөлденген үлкен сөздері бар екі қос сөз жіберіледі. Мұндай операция үшін МП-ның MOVZX командасы қолайлы, ол үлкен сөздің биттері нөлдермен толтырылатындай екінші операндты біріншіге көшірмелейді. Егер де параметрлер қос сөздер болса, онда %u алаңының орнына %lu –ды қояр едік. Пішімді жолдың алаңы параметрлер жолын, мысалы “%s”-ті анықтаған жағдайда, стекке жолға нұсқағышты жіберу керек.
4 кесте - KEY_EVENT жағдайы
|
Жылжу |
Ұзындық |
Мағынасы |
|
+4 |
4 |
Пернені басқанда өріс мәні нөлден үлкен |
|
+8 |
2 |
Пернені ұстап тұрғандағы қайталаулар саны |
|
+10 |
2 |
Перненің кодтауы |
|
+12 |
2 |
Перненің скан-шарттаңбасы |
|
+14 |
2 |
ReadConsoleІnput A функциясы үшін кіші байт ASCІІ-перне шарттаңбасына тең. ReadConsoleІnput W функциясы үшін сөздің екі байтты кодтамадағы (Unіcode) перненің шарттаңбасы бар |
|
+16 |
4 |
Басқарушы пернелердің жағдайы бар. Ол келесі тұрақтылардың қосындысы бола алады: RІGHT_ALT_PRESSED equ 1h LEFT_ALT_PRESSED equ 2h RІGHT_CTRL_PRESSED equ 4h LEFT_CTRL_PRESSED equ 8h SHІFT_PRESSED equ 10h NUMLOCK_ON equ 20h SCROLLLOCK_ON equ 40h CAPSLOCK_ON equ 80h ENHANCED_KEY equ 100h Тұрақтылар мағынасы айқын |
Функция оған қанша параметр жіберілетінін “білмегендіктен”, өндірушілер осы функцияның мәтінін қиындатпады да, бізге стектің босатылу проблемасын қалдырады. Бұл ADD ESP, N командасы көмегімен жүзеге асырылады, мұндағы N-босатылатын байттар саны.
Егер жағдайлар арашығы бос болса, онда функция консольдық тереземен бір жағдай болғанға дейін күтеді және тек сонда басқаруды қайтарады. Бұдан басқа біз функцияға консольмен болған бір емес, бірнеше жағдайлар туралы жазылымдарды қайтаруды нұсқай аламыз. Бұл жағдайда арашыққа бір емес бірнеше ақпараттық жазылымдар орнатылады.
1. Леффингуал, Дин, Ундри, Дон Принципы работы с требованиями к ПО. Унифицированный подход. - М.: «ВШ», 2002.
2. Сэм Канер и др. Тестирования программного обеспечения. - Киев: «ВШ», 2000.
3. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки ПО. - М.: «ВШ», 2000.
4. Крэг Ларман Применение UML и шаблонов проектирования. - М.: «Вильямс», 2001.
5. Шниер Толковый словарь компьютерных технологий. – М.: «Вильямс», 2002.
6. Тексейра Стив и Пачеко Ксавье Delphi 7. Руководство разработчика. Т.1,2. – М.: Вильямс, 2006.
7. Шмуллер Дж. Освой самостоятельно UML 2.0. - М.: «Вильямс», 2006.
8. Орлов С.А. Технологии разработки программного обеспечения. - СПб: «Питер», 2002.
9. Гиббс Р. Денис Управление проектами с помощью IBM Rational Unified Process. - М.: «Кудиц-Пресс», 2007.
10. Кватрани Терри, Палистрант Джим Визуальное моделирование с помощью IBM Rational Sostware Architect и UML. - М.: «Кудиц-Пресс», 2007.
11. Тампе Луиза Введение в тестирование программного обеспечения. - М.: «Вильямс», 2003.
12. Соммервилл Иан Инженерия программного обеспечения. - М.: «Вильямс», 2002.
13. КТ кафедрасында сервердегі ақпарттардың электрондық түрінде (ауд.С307) – Far, MS Visual Studio, С++ Builder, Delphi және т.б.
Мазмұны
|
1 дәріс. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС даму тарихы |
3 |
|
2 дәріс. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын анықтау. RUP |
6 |
|
3 дәріс. Талаптарды өңдеу. Логикалық жобалау аспаптары мен әдістері |
11 |
|
4, 5 дәріс. UML. Өңдеудің функционалдығын сипаттау. Аспаптары мен әдістері |
14 |
|
6 дәріс. Кластар диаграммасын құру. Әдістері, технологиялары, аспаптары |
18 |
|
7, 8 дәріс. Өңдеу тілін, тарату ортасын және өңдеу аспаптарын анықтау |
20 |
|
9 дәріс. Физикалық жобалау процедурасы – тәртібі, аспабы, ресурсы, құжаттары |
26 |
|
10, 11 дәріс. Визуальды программалау құралдары – MS Visual Studio, Borland Delphi және т.б. |
32 |
|
12 дәріс. Компонентерді таңдау және редакторлау, компонентті өңдеу. Open ТOOLs API |
40 |
|
13, 14 дәріс. Программа интерфейсін құру. Аспаптарды өңдеу принциптары. Интерфейс құру әдістері және аспаптық құралдары |
44 |
|
15 дәріс. Программның жөнделуі. Аспаптары. Жөндеу әдістемесі |
48 |
|
Әдебиеттер тізімі |
53 |
2012 ж. баспа жоспары, реті 358