Бағдарламаларды әзірлеудің құрал-саймандары пәнінен дәрістер
Тақырып 1. Пән . стандарттары және өңдеу процессі. (4 сағат)
Дәріс №1. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС даму тарихы.
Дәріс №2. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын анықтау. RUP. (2 сағ)
Тақырып 2. Логикалық жобалау. (6 сағат)
Дәріс №3. Талаптарды өңдеу. ТТ. Логикалық жобалау аспаптары мен әдістері.
Дәріс 4. UML. Өңдеудің функционалдығын сипаттау. Аспаптары мен әдістері. (2 сағ)
Дәріс 5. Кластар диаграммасын құру. Әдістері, технологиялары, аспаптары. (2 сағ)
Тақырып 3. Өңдеу ортасы және аспаптарды таңдау. (2 сағат)
Тақырып 4. Программаның физикалық жобалануы.(8 сағат)
Дәріс 7. Физикалық жобалау процедурасы . тәртібі, аспабы, ресурсы, құжаттары (2 сағ)
Дәріс 8. Визуальды программалау құралдары . MS Visual Studio, Borland Delphi және т.б.
Дәріс 9. Компонентерді таңдау және редакторлау, компонентті өңдеу. Open ТOOLs API.
Дәріс 10. Программа интерфейсін құру. Аспаптарды өңдеу принциптары. Интерфейс құру әдістері және аспаптық құралдары. (2 сағ)
Тақырып 5. Программаларды тестілеу және жөндеу. (3 сағат)
Дәріс 11. Программның жөнделуі. Аспаптары. Жөндеу әдістемесі. (3 сағ)
Дәріс №1. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС даму тарихы.
Дәріс №2. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын анықтау. RUP. (2 сағ)
Тақырып 2. Логикалық жобалау. (6 сағат)
Дәріс №3. Талаптарды өңдеу. ТТ. Логикалық жобалау аспаптары мен әдістері.
Дәріс 4. UML. Өңдеудің функционалдығын сипаттау. Аспаптары мен әдістері. (2 сағ)
Дәріс 5. Кластар диаграммасын құру. Әдістері, технологиялары, аспаптары. (2 сағ)
Тақырып 3. Өңдеу ортасы және аспаптарды таңдау. (2 сағат)
Тақырып 4. Программаның физикалық жобалануы.(8 сағат)
Дәріс 7. Физикалық жобалау процедурасы . тәртібі, аспабы, ресурсы, құжаттары (2 сағ)
Дәріс 8. Визуальды программалау құралдары . MS Visual Studio, Borland Delphi және т.б.
Дәріс 9. Компонентерді таңдау және редакторлау, компонентті өңдеу. Open ТOOLs API.
Дәріс 10. Программа интерфейсін құру. Аспаптарды өңдеу принциптары. Интерфейс құру әдістері және аспаптық құралдары. (2 сағ)
Тақырып 5. Программаларды тестілеу және жөндеу. (3 сағат)
Дәріс 11. Программның жөнделуі. Аспаптары. Жөндеу әдістемесі. (3 сағ)
Түсініктемелерді анықтау: программа, деңгейлері және категориялары (бағыттары) программалау, программаны өңдеу және аспаптары. Аспаптар, ол жұмысты орындау үшін арналған құралдар, яғни программаны өңдеу және тарату екі топқа бөлінеді аппараттық және программалық. Аппараттық – микропроцессорлар және қосылатын (сыртқы) құрылғылар. Программалық – олар жобалау методологиясымен анықталған, барлық жұмыстарды орындауға мүмкіндік беретін программалар. Беріліп отырған пән негізінен, компьютерге программаларды орнату және өңдеу үшін қолданылатын программалық аспаптық құралдарды оқып үйренуге арналған. Программалық өнімді (ПӨ) өңдеу көптеген бір-бірімен байланысқан әрекеттерден тұрады, олар:
- деректер моделін құру және есептеу әдістемесі;
- есептеуді қамтамасыздандыратын, функциональдық сипаттамасы;
- деректер құрылымын анықтау – компьютерде және алгоритмде көрсетілу моделі;
- есепті тарату әдістерін сипаттау және анықтау (тестер және шешу алгоритмі);
- пайдаланушы интерфейсін сипаттау және анықтау;
- ПӨ қолдау құралдарын анықтау;
- есеп спецификациясы;
- тестілеу программасын қоса отырып, программа текстін жазу;
- программаның тестіленуі, трансляциясы және жөнделуі;
- қолдау кітапханаларын қосу және байланыстыру;
- орындау ортасын құру; орындамалық модулді орналастыру және жүктеу;
- орнатылған көмекті құру және өңдеуді құжаттау;
- орнатылатын (инсталляциялық) ПӨ пакетін құру.
Rational Unified Process (RUP) аймағында программаларды өңдеуге арналған әрекеттер жиыны келесі этаптардан тұрады: - талаптарды анықтау; - жобалау; - программалау; - тестілеу; -ендіру.
Көрсетілген жұмыстарды орындау үшін көптеген программалар жиынтығы үнемі өңделіп және толықтырылып отырады – ол аспаптар, программаның өңделу процессін автоматтандыру және қалыптастыру үшін мүмкіндік береді. Бұл құралдарды қолдану өңдеу және программалық өнімді енгізу уақытын азайтады.
Компьютер үшін программа – бұл программалау тілінде құрылған немесе жазылған, тәртіптер тізімі. Программалау тілі берілген есепті шешу үшін және тиімді, жылдам, сапалы, экономды жобалау мақсатында таңдалады.
Тіл деңгейі – программалау деңгейі. Тіл деңгейі – программалау деңгейі. Төменгідеңгейлі программалау – бұл микропроцессор деректер форматын және командаларын кодтық немесе мнемоникалық формада (ассемблер) қолданатын программалау. Проблемалы – бағытталған программалау (текстуальды) – бұл деректер форматын және командаларын проблемалы – бағытталған тілдерде программалау. Визуальды программалау – бұл деректер форматын және командаларын программаларды өңдеудің визуальды құралдары арқылы программалау.Обьектілік немесе компоненттік программалау әртүрлі конструктивтерді бірлік элемент ретінде қолдануға мүмкіндік береді.
Командалық (атомарлы), құрылымдық, модульдік программалау – категориялары, программаларды өңдеу кезінде қолданылатын тілдің типтік конструкциясымен анықталады. Құрылатын программа үшін, проблемалы аймақ, программалаудың бағытын анықтайды – ғылыми түрде, бизнес есептерін шешу үшін, обьектілер мен процесстерді басқару үшін, ақпараттарды көрсету және басқару үшін, Интернет пен қарым – қатынас жасау үшін, деректер қорымен қарым – қатынас жасау үшін және т.б. қолданылады.
Құрылымдық программалау концепциясы.
- деректер моделін құру және есептеу әдістемесі;
- есептеуді қамтамасыздандыратын, функциональдық сипаттамасы;
- деректер құрылымын анықтау – компьютерде және алгоритмде көрсетілу моделі;
- есепті тарату әдістерін сипаттау және анықтау (тестер және шешу алгоритмі);
- пайдаланушы интерфейсін сипаттау және анықтау;
- ПӨ қолдау құралдарын анықтау;
- есеп спецификациясы;
- тестілеу программасын қоса отырып, программа текстін жазу;
- программаның тестіленуі, трансляциясы және жөнделуі;
- қолдау кітапханаларын қосу және байланыстыру;
- орындау ортасын құру; орындамалық модулді орналастыру және жүктеу;
- орнатылған көмекті құру және өңдеуді құжаттау;
- орнатылатын (инсталляциялық) ПӨ пакетін құру.
Rational Unified Process (RUP) аймағында программаларды өңдеуге арналған әрекеттер жиыны келесі этаптардан тұрады: - талаптарды анықтау; - жобалау; - программалау; - тестілеу; -ендіру.
Көрсетілген жұмыстарды орындау үшін көптеген программалар жиынтығы үнемі өңделіп және толықтырылып отырады – ол аспаптар, программаның өңделу процессін автоматтандыру және қалыптастыру үшін мүмкіндік береді. Бұл құралдарды қолдану өңдеу және программалық өнімді енгізу уақытын азайтады.
Компьютер үшін программа – бұл программалау тілінде құрылған немесе жазылған, тәртіптер тізімі. Программалау тілі берілген есепті шешу үшін және тиімді, жылдам, сапалы, экономды жобалау мақсатында таңдалады.
Тіл деңгейі – программалау деңгейі. Тіл деңгейі – программалау деңгейі. Төменгідеңгейлі программалау – бұл микропроцессор деректер форматын және командаларын кодтық немесе мнемоникалық формада (ассемблер) қолданатын программалау. Проблемалы – бағытталған программалау (текстуальды) – бұл деректер форматын және командаларын проблемалы – бағытталған тілдерде программалау. Визуальды программалау – бұл деректер форматын және командаларын программаларды өңдеудің визуальды құралдары арқылы программалау.Обьектілік немесе компоненттік программалау әртүрлі конструктивтерді бірлік элемент ретінде қолдануға мүмкіндік береді.
Командалық (атомарлы), құрылымдық, модульдік программалау – категориялары, программаларды өңдеу кезінде қолданылатын тілдің типтік конструкциясымен анықталады. Құрылатын программа үшін, проблемалы аймақ, программалаудың бағытын анықтайды – ғылыми түрде, бизнес есептерін шешу үшін, обьектілер мен процесстерді басқару үшін, ақпараттарды көрсету және басқару үшін, Интернет пен қарым – қатынас жасау үшін, деректер қорымен қарым – қатынас жасау үшін және т.б. қолданылады.
Құрылымдық программалау концепциясы.
Пән: Информатика, Программалау, Мәліметтер қоры
Жұмыс түрі: Материал
Тегін: Антиплагиат
Көлемі: 40 бет
Таңдаулыға:
Жұмыс түрі: Материал
Тегін: Антиплагиат
Көлемі: 40 бет
Таңдаулыға:
Дәрістік сабақ конспектілері
Тақырып 1. Пән – стандарттары және өңдеу процессі. (4 сағат)
Дәріс №1. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС
даму тарихы. (2 сағ)
Түсініктемелерді анықтау: программа, деңгейлері және категориялары
(бағыттары) программалау, программаны өңдеу және аспаптары. Аспаптар, ол
жұмысты орындау үшін арналған құралдар, яғни программаны өңдеу және тарату
екі топқа бөлінеді аппараттық және программалық. Аппараттық –
микропроцессорлар және қосылатын (сыртқы) құрылғылар. Программалық – олар
жобалау методологиясымен анықталған, барлық жұмыстарды орындауға мүмкіндік
беретін программалар. Беріліп отырған пән негізінен, компьютерге
программаларды орнату және өңдеу үшін қолданылатын программалық аспаптық
құралдарды оқып үйренуге арналған. Программалық өнімді (ПӨ) өңдеу көптеген
бір-бірімен байланысқан әрекеттерден тұрады, олар:
- деректер моделін құру және есептеу әдістемесі;
- есептеуді қамтамасыздандыратын, функциональдық сипаттамасы;
- деректер құрылымын анықтау – компьютерде және алгоритмде көрсетілу
моделі;
- есепті тарату әдістерін сипаттау және анықтау (тестер және шешу
алгоритмі);
- пайдаланушы интерфейсін сипаттау және анықтау;
- ПӨ қолдау құралдарын анықтау;
- есеп спецификациясы;
- тестілеу программасын қоса отырып, программа текстін жазу;
- программаның тестіленуі, трансляциясы және жөнделуі;
- қолдау кітапханаларын қосу және байланыстыру;
- орындау ортасын құру; орындамалық модулді орналастыру және жүктеу;
- орнатылған көмекті құру және өңдеуді құжаттау;
- орнатылатын (инсталляциялық) ПӨ пакетін құру.
Rational Unified Process (RUP) аймағында программаларды өңдеуге арналған
әрекеттер жиыны келесі этаптардан тұрады: - талаптарды анықтау; - жобалау;
- программалау; - тестілеу; -ендіру.
Көрсетілген жұмыстарды орындау үшін көптеген программалар жиынтығы үнемі
өңделіп және толықтырылып отырады – ол аспаптар, программаның өңделу
процессін автоматтандыру және қалыптастыру үшін мүмкіндік береді. Бұл
құралдарды қолдану өңдеу және программалық өнімді енгізу уақытын азайтады.
Компьютер үшін программа – бұл программалау тілінде құрылған немесе
жазылған, тәртіптер тізімі. Программалау тілі берілген есепті шешу үшін
және тиімді, жылдам, сапалы, экономды жобалау мақсатында таңдалады.
Тіл деңгейі – программалау деңгейі. Тіл деңгейі – программалау деңгейі.
Төменгідеңгейлі программалау – бұл микропроцессор деректер форматын және
командаларын кодтық немесе мнемоникалық формада (ассемблер) қолданатын
программалау. Проблемалы – бағытталған программалау (текстуальды) – бұл
деректер форматын және командаларын проблемалы – бағытталған тілдерде
программалау. Визуальды программалау – бұл деректер форматын және
командаларын программаларды өңдеудің визуальды құралдары арқылы
программалау.Обьектілік немесе компоненттік программалау әртүрлі
конструктивтерді бірлік элемент ретінде қолдануға мүмкіндік береді.
Командалық (атомарлы), құрылымдық, модульдік программалау –
категориялары, программаларды өңдеу кезінде қолданылатын тілдің типтік
конструкциясымен анықталады. Құрылатын программа үшін, проблемалы аймақ,
программалаудың бағытын анықтайды – ғылыми түрде, бизнес есептерін шешу
үшін, обьектілер мен процесстерді басқару үшін, ақпараттарды көрсету және
басқару үшін, Интернет пен қарым – қатынас жасау үшін, деректер қорымен
қарым – қатынас жасау үшін және т.б. қолданылады.
Құрылымдық программалау концепциясы.
Құрылымдық программалау – программалау методологиясы, жүйелік түрдегі
талдауға негізделген, ПҚ тарату және жобалау. 70 – жылдардың басында пайда
болды және соншалықты өміршең, сондықтан да осы күнге дейін пайдаланылады.
Бұл технологияның негізі келесі тәртіптерден тұрады:
• Қиын есептер кішірек бөліктерге бөлінеді, функциональды түрде негізінен
басқарылатын есептер дұрыс. Әрбір есептің бір кірісі және бір шығысы
болады. Бұл жағдайда программа ағымы көптеген есептер тобынан және
түсінікті функционалдық тағайындамасынан құралады.
• Есепте қолданылатын, басқарылатын құрылымның қарапайымдылығы және
атомарлығы. Бұл, логикалық есеп минималды, функционалды толық қалыптасқан
қарапайым басқарылатын құрылымнан тұруы керек екендігін көрсетеді.
• Программаның өңделуі этап бойынша орындалады. Әрбір этапта шектелген есеп
саны, нақты қойылған тапсырмасымен және есеп барысындағы оның атқаратын
мәнімен, түсінікті қойылымы шешілуі керек. Егер ондай шамаға жетпесе,
онда ол бұл этап өте үлкен және оны тағы басқа қадамдарға бөлу керек
екендігін білдіреді.
Модулдік программалау концепциясы.
Құрылымдық технология сияқты мұнда да, модулдік программалау концепциясын
бірнеше түсініктемелер және тәртіптер түрінде қалыптастыруға болады:
• Есептің функциональдық декомпозициясы – үлкен есепті кіші есептерге бөлу,
олар функциональды өзбектінше орындалатын ішкіесептер - модулдер.
Модулдер өзара кіріс және шығыс деректерімен байланысқан.
• Модуль - модулдік программалау концепциясының негізі. Әрбір модульдің
функциональдық декомпозициясы бір кірісі және бір шығысы бар "қара жәшік"
ретінде қаралады. Модульдік көзқарас программаның модернизациясын
процесстің эксплуатациясы кезінде ешбір қатерсіз орындауға мүмкіндік
береді және оны қолдап отырады. Қосымша модулдік программалау бір жобаның
программасының әртүрлі бөліктерін әртүрлі программалау тілдерінде
орындауға мүмкіндік береді, одан кейін компоновкалау құралдары арқылы
оларды бір жүктемелеу модуліне біріктіреді.
• Таратылатын шешімдер қарапйым және түсінікті болуы керек. Егер модульдің
атқаратын қызметі түсініксіз болса, онда бастапқы немесе аралық
декомпозиция есептері дұрыс, керек еткен дейгейде, сапалы жүрмегендігін
білдіреді. Бұл жағдайда есепті қайта талдау керек, мүмкін, қайта бөлулер
жасау, яғни ішкіесептерге бөлу жұмыстарын орындау керек болады. Жобада
қиын орындалатын орындар кездессе, онда оларды жүйемен ойластырылған
комментарилер арқылы құжаттау керек. Бұл процесс модулдердің жұмысының
толық түсінікті, қызметтері анықталған және байланыстырылғанға дейін
қайталана береді.
• Модулдің барлық айнымалыларның қызметі комментерилердің көмегімен
анықталуы және жазылуы керек.
Объектілі-бағыттылған парадигма.
ОБП идеясы негізінен осы деректерді өңдейтін процедураларды бір бүтін -
обьектіге байланыстыру үшін жасалған. ОБП маңызды үш принцип негізінде
құрылған, олар обьектілерге жаңа қасиеттер береді. Бұл принциптар ретінде
инкапсуляция, мұрагерлену және полиморфизм алынады.
• Инкапсуляция – Осы деректерді өңдеу алгоритмдері мен деректерді бір
бүтінге біріктіру. ОБП деректері көлемінде – объект полесі,
алгоритмдері – объектілік әдістер алынады. Полелер мен алгоритмдер
іштен қолданылады, - жалпы, сырттан немесе тек обьект ішінде – соған
тәуелді, ішкілер немесе байланысқан обьектілер – қорғалған.
• Мұрагерлену – обьектілер қасиеті өздерінің мұрагерлерін туындайды және
оларға өздерінің қасиеттерін үнсіздікпен ұсынады. Объект -
мұрагерленуші, ол қасиеттерді толықтыра алады немесе басқамен оны
ауыстыра (орынбастыра) алады.
• Полиморфизм – туыстық обьектілердің қасиеттері (яғни бір объектіден
тараған бір түбірі бар обьектілер) негізінен бір – біріне ұқсас, мәні
жағынан бірдей проблемаларды әртүрлі әдістермен, оның уақытына және
орналасу ретіне байланысты шешу.
Программаны өңдеу үшін алынған аспап таңдалған деңгей негізімен, бағытымен,
өңдеу категориясымен анықталады және текстуальды немесе визуальды түрде
беріледі. Қазіргі заманғы программалау – компоненттік (объектілік),
уақиғалық және визуальды болып алынады. Түсініктемені анықтайтын болсақ.
Программаны өңдеу мемлекеттік және шетелдік стандартқа сәйкес, өңдеуші
ұсынған технологиялар мен әдістемелер немесе типтік программалар арқылы
орындалады.
Аспаптық құралдардың классификациясы. Өңдеу процессі және таратылуының орны
бойынша, уақытша принципі бойынша, қолданылатын технологиялары мен
әдістемесі бойынша, продукт сапасы бойынша және т.б.
Пән мақсаты мен міндеттері. Силлабуста берілген.
Программаны өңдеу процедурасындағы аспаптық құралдардың орны мен атқаратын
қызметі. Әрбір программаны өңдеу этабының өз аспаптар жиыны бар. Силлабуста
барлық өңдеу қадамдары көрсетілген. Әрбір қадам өңдеу нәтижесімен
анықталады – негізгі құжат болып, және қосымша құжат болып, этапты жабу
алынады. Аспап, сәйкесінше, негізгі немесе қосымша болады.
Сапа мінездемесі және аспапты қолдану. Жазықтықтағы, уақытша, тұрақты,
берік, қазіргі заманғы, интуитивті түсініктер, визуальды, статикалық және
динамикалық, өңдеуді түзету және өзгертуді қамтамасыздандыру, нәтижеге
байланысты, сәйкес стандарттар мен технологиялар, мақсатың орындалуымен
және т.б.
Аспаптық құралдардың дамуына қысқаша түсініктеме. Этаптар 1960 – 1975 –
1985 – 2000 жылдар. Тілдер, компиляторлар, компоновщиктер, құрастырушылар,
жүктемелегіштер, операциялық жүйелер, өңдеу құралдары және тестілеу,
енгізу құралдары және программаны қолдау. Соңғы 20 жыл ішіндегі
программалау тілдерінің даму схемасы.
Бақылау сұрақтары:
1. Программа дегеніміз не?
2. Аспап дегеніміз не?
3. Программалаудың деңгейлері мен категорияларын атаңыз?
Дәріс №2. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын
анықтау. RUP. (2 сағ)
Жобалау әдістер және программаның өміршендік циклын қамтамасыздандыру.
Командалық және жеке жобалау және оған керекті аспаптар. Текстуальды және
визуальды жобалау – технологиялары және әдістемесі, қолданатын аспаптары.
Визуалды модельдеу дегеніміз не? Визуальды модельдеу (vіsual modelіng) –
нақты өмірдің объектілері мен ұғымдарын көрсететін және өзі көрініс табатын
абстракциялардың көмегімен проблемаларды қабылдау әдісі. Модельдеу
проблемаларын талдау, барлық қызығушылығы бар жақтар арасында ақпараттардың
алмасуы (қолданушылар, пәндік аумақтағы мамандар, аналитиктер, дизайнерлер
және т.б.), программалық қолданбалар мен мәліметтер базасын жобалау, және
документацияны дайындау үшін пайдалы құрал болып табылады. Модельдеу
талаптарын жақсы қабылдауға, жүйенің дизайн сапасын жақсартуға және оны
басқару деңгейін жоғарылатуға өз септігін тигізеді. UML – объекті
бағдарланған жүйелермен құрастырылатын мәндердің документациясын белгілеу
мен көріністендіру үшін қолданылатын тіл.
Модельдің көмегімен біз керегі жоқ детальдарды қарастырмай-ақ бар
назарымызды негізгіге аудара отырып, проблеманы оңайлатуымыз мүмкін.
Абстракциялау мүмкіндігі – күрделік феноменін шешуге көмектесетін, адам
интеллектісінің іргелі қасиеті. Мыңдаған жылдар барысында суретшілер, қол
өнершілер және құрылысшылар нақты шығармашлық ойларды жүзеге асыру алдында
түрлі модельдерді жобалау талпыныстарын жасаған. Бұл құбылыстар
программалық қамтаманы жасау индустриясын айналып өткен жоқ. Күрделі
программалық жүйені құрастыру үшін, автор оның қасиеттерін түрлі
көзқарастар тарапынан абстракциялауға, белгілеулердің нақты жүйелерінің
көмегімен модельдерді жобалауға, олардың бастапқы талаптарға сәйкестігін
тексеріп алуға міндетті, тек содан кейін ғана жүйені жаңа функциялармен
толықтыра отырып, модельді практикада жүзеге асыруға болады.
12207 стандарты – Программалық жүйенің өміршендік циклының процесстері
(ПЖ ӨЦ). Есептерді, жұмыстарды, процесстерді анықтайды. Кімге
тағайындалғанын зерттейді. Нақты адаптация және шектеулер. Нормативті
сілтемелер. Анықтамалар. Стандарттың қолданбалы қолдану – 5 негізгі, 8
қосымша, 4 ұйымдастыру процесстері. Өңдеу программасы – талаптардың
талдануы, жобалау, программалау, жинау, тестілеу, орындау үшін енгізу,
қабылдау. Этап бойынша жұмыстар тізімі. Этап бойынша жұмыстар мазмұны.
Аспаптары.
Қазіріг заманғы аспаптық құралдар. Барлық өңдеу этаптарын
визуализациялау. Визуальды технологиялар негізі. Өңдеу ортасы, обьектілер,
компоненттер кітапханасы. Аспаптар дайындау фирмаларының талдануы.
Талданудың интерфейстік құрамы. Интерфейс стандарттары. Қазіргі заманғы
визуальды аспатардың құрамы. Программаларды өңдеу аспаптарының құрамын
жобалаудың бірлік ұстанымдары және олардың әртүрлілігі.
RUP технологиясы, олардың өңдеу құжаттары және фазалары, аспаптары.
Rational Unified Process Бүгінгі күнде ол ең көп кездесетін
әдістемелердің бірі. Ол Rational Software копаниясымен өз өнімдерін қолдау
үшін шығарылған, олар оннан көп деп есептелінеді (ең көп кездесетін
өнімдеріне - Rational Rose және Requisite Proжатады). RUP үш атақты
адамдармен құрылған - бұлар Гради Буч, Ивар Якобсон және Джеймс Рамбо
(Rumbaugh). Олардың барлығы қиын программалық қамтаманы өндеуде үлкен
жетістіктерге жеткен адамдар, оны RUP бейнесінен – ақ көруге болады. RUP
Итеративтігі, қазіргі заманғы дамыған кез – келген процесс сияқты, ол да
итеративті болып табылады. Бұл яғни, құрылатын жоба бірнеше итерациямен
орындалатындығын көрсетеді. Әрбір итерация аяғында жұмыс жасайтын өнім
версиясын алуға мүмкіндіктер бар, бірақ олардың функционалдығы толық емес.
Одан кейін орындалатын итерацияларда функционалдылық толықтырылып отырады
да, соңында дайын өнім ала аламыз. Итеративті өнім идеясынның процессін
келесі түрде көрсетуге болады (сурет 1, қара).
Сурет. 1.Спиральдің әрбір
бөлігі - итерация. Яғни жүйе
функционалдығы біртіндеп
өсіп отырады.
Итеративті өңдеудің артықшылықтары көп. Релиздердің көп бөлігі өнім
сапасына ықпалын тигізеді, олар әрбір итерация сайын тестіленіп отырады.
Яғни бастапқы тексерулер жүргізілгеннен кейін-ақ пайдаланушы күткен өнімді
алуға мүмкіндіктер бар және өзгертулерді сол кезде енгізуге болады, егер ол
қажет болса. Сонымен - қатар, жобаны жоспарлау да оңай, өйткені бірінші
итерациядан кейін ақ ол түсінікті болады, және жобаны басқарушы келесі
итерацияның аяқталу уақытын да алдын – ала жоспарлауға мүмкіндігі болады.
Айта кететін жағдай, 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 стандарттары және т.б.
Аспаптық құралдарға стандарттардың таратылуы. Өңдеудің визуальды
элементерінің жиынын дайындау. Элементтер кітапханасының құрамын жедел
құрастыру мүмкіндіктері. Жобалаудың жетіспейтін стандартты элементтерін
қосу. Өзгертудің оперативтігі.
Ақпаратты қорғау стандарттары. Р511.88-98. Ақпаратты қорғау. Программалық
құралдарды компьютерлік вирустардың бар жоқтығына тексеру. Р512.41- 98.
Қатынауды басқару, бақылау жүйесі және құралдары. Классификациясы. Жалпы
техникалық талаптар. Тексеру әдістері. Кодтың комбинация мәндері –
санкцияланбаған қатынаудан қорғау тұрақтылығы. Қатынауды басқарудың жабдық
программасы не істеуі керек? Программаның әрекеттерге тұрақтылығы.
Бақылау сұрақтары:
1. Программаны өңдеу процесінің құрамын және тәртібін негізгі қандай ГОСТ-
лар анықтайды?
2. Пәнді оқып үйренуді қалай ұйымдастыруға болады?
3. Программаны өңдеу процесінің этаптары?
4. Жоғарғы деңгей қорғанысындағы кілттер жинына қатынау талаптарын
атаңың?
5. Өңдеу сапасын қамтамасыздандыру мінездемесі қандай?
6. RUP-тағы артефакт дегеніміз не?
7. Программа дегеніміз не?
8. Программалаудың қандай деңгейлері мен бағыттарын білесіз?
9. Аспап дегеніміз не және программаны өңдеу процессі кезінде қандай
аспаптар қолданылады?
10. Утилиттер дегеніміз не және қандай утилиттерді білесіз?
11. ПӨ менюіндегі TOOLS сөзін қалай түсінесіз?
Тақырып 2. Логикалық жобалау. (6 сағат)
Дәріс №3. Талаптарды өңдеу. ТТ. Логикалық жобалау аспаптары мен
әдістері.
Жобалаудың логикалық фазасы – программалық өнімнің алдын-ала өңдеу
фазасы. Менде алты құл бар. Олар ақылды, талпынғыш. Менің білетінімнің
бәрі, солардың арқасы. ... Олардың аттары : қалай және неге, кім, не, қашан
және қайда - логикалық модел құру үшін керекті сұрақтар құрамының
парадигмасы. Пәндік аймақтың талдануының және сипаттамасының - этаптары,
алгоритмдер мен деректер моделінің логикалық құрылуы, олардың байланысы
және пайдаланушыға берілуі. Стандарттар. Техникалық тапсырма (ТТ) –
өңдеуге берілетін талаптардың нәтижесі. ТТ құрамы. Өңдеудің ашылған бар
әдістемесі, және олардың қазіргі заманғы құралдарда қолданылуы мен
элементтері. Өңдеу этаптарын алдын – ала спецификациялау және оның ТТ әсер
етуі. Аспаптар – мүмкіндіктері, технологиялары, жұмыс әдістемесі.
Құрылымдық, модульдік және обьектілік ұстанымдар – айырмашылықтары мен
ұқсастықтары. Итерация, комбинирлеу және жоғарыдан – төмен немесе төменнен
– жоғары жобалау.
UML талдау мен жобалау үрдістерінің құрамдас бөліктерін – семантикалық
модельдер, синтаксикалық нотация мен диаграмманы, стандартизациялаудың
сәтті талпынысы.
UML диаграммалары және класстар диграммасын құру тізбегі. Rational Rose
– UML әдістемесін тарату аспабы. Ұқсас есептерді шешу үшін қолданылатын
басқа да визуальды аспаптар. Өңдеу функциянальдығын сипаттау – қолдану
варианттар диаграммасы (талаптар және шектеулер), функция орындалу реттері
– әрекеттердің тізбектер диаграммасы (талаптар және шектеулер), өңдеу
элементерінің бір-бірімен байланыс және бар болу сипаттамасы – кооперативті
диаграммалар (талаптар және шектеулер). Интерфейсті жобалау. Обьектілік
жобаның өңделуі, ОМ 6 қосымшасына сәйкес, негізінен прецеденттер
диаграммасы (ПД) немесе, екінші аталуы – ''Қолдану варианттар
диаграммасы'' (ҚВД) басталады. Диаграмма прецедент барлық қалған жоба
диграммалары үшін арналып жасалады. Ал оның екінші аталуы, негізінен, оның
атқаратын рольін толық көрсетеді деп айтуға болады – пайдаланушы жүйесінің
қолдану варианттар диаграммасы (актерлар, әрекет жасаушы обьект). Сонымен
бұл диаграмма негізінен, егер бұл ұстанымды Коуда (Сoad) атымен беріп
орындайтын болсақ, онда жобалаушы сұрақтарына жауап ретінде - кім, қашан
және не істегендігін білуге болады. Келесі диаграмма – ''Тізбек
диаграммасы'' – Қ.В. (жеке қолдану вариантын орындау) орындауды жеке
түсіндіреді (Қ.В.). Бұл диаграммада, егер Коуда әдістемесін қолданатын
болсақ, онда актер вариантты орындау кезінде кіммен (немен)
байланысқандығы көрсетіледі. Бұл диаграммада Қ.В. орындау уақыты
анықталады, ол жүйеге нақты уақыт (RTS) жүйесінің қалай қызмет
көрсететіндігін көрсетеді және жүйе, ON-LINE типінде, реакцияны шектеумен
ерекшеленетіндігін де көрсетеді. Бұл диаграммада вариантты қолданушылардың
арасындағы өтулер қолданушы әрекетімен анықталады. Сонымен қолданылатын
Қ.В. обьектіге кандидат (немесе обьект атрибуты) болып табылады, ал ол
орындайтын әрекет – обьектінің әдісінің кандидаты болып табылады.
Сондықтан, диаграмма обьектілерді анықтаудың негізі болып табылатындығын
айтып кетуге болады. Бұл диаграммада қолданушылар ретінде интерфейстің
қолданылып отырған элементтерін және басқа ақпараттық обьектілерді алуға
болады.
Объект нақты немесе абстрактылы мән ретінде болады.
Объект дегеніміз – программалық қосымшада нақты бір шекаралар , мағыналар
және мәндермен берілген түсінік немесе абстракция.
Жүйенің әрбір объектісінің үш сипаттамасы болады-
жағдайы, тәртібі және біркелкілік белгісі. Объект жағдайы атрибуттар
–касиеттернінің жиынтығы және басқа абстракциямен байланыс арқылы
анықталады. Мінез-құлық сипаттамасы объектінің функционалдық өмірін қамтуы,
басқа объектер сұранысына әсерін зерттеп және операциялар жиыны түрінде
іске асырылады. Біркелкілік белгісі объектінің әмбебаптығын анықтайды –
басқа объектілермен бірдей болған жағдайда даклас объетілер тобын ортақ
(атрибуттар) , қасиеттер , мінез-құлық(функционалдар), семантика және басқа
объектілер мен байланыс арқылы анықтайды. Класты басқаша объектні құруға
арналған шаблон деп те атауға болады. Әрбір объект тек бір кластың данасы
болып табылады. Класты құрған кезде оны құжаттандыру керек. Сипаттама класс
құрылымын емес, оның мәнін беру керек.
Ratіonal Rose өнімдерінің сериясы құрастырушыны нақты уақыт жүйелерінде
және клиентсервер орталарында қолдануға жарайтын және қазіргі кездегі
бизнес талаптарын қанағаттандыратын тиімді де сенімді шешімдерді қабылдауға
көмектесетін визуалдық модельдеудің толық құралдар жиынымен қамтамасыз
етеді. Ratіonal Rose құралдары біркелкі стандарттарға негізделген және
модельдеуді, оларға жақын сфералардағы бизнес-процестерді оптимизациялауға
талаптанатын, компьютерлік ғылымдармен онша таныс емес тұлғалармен қатар,
программалық қолданбалардың логикасын модельдеу құралдарын қажет ететін
мамандар үшін оңай етеді.
Келесі қолданылатын RR – мен берілген диаграммаларға, - кооперативтік
диаграммаларды жатқызуға болады, - олпар негізінен тәртіп детализациясы
үшін қолданылады, олар уақиғалар аймағын және олардың арасындағы байланысты
анықтайды, қосымша қолданушыларды анықтайды, олардың жалпы және
мінездемелік анықталарын береді – яғни соңғы Класстар диаграммасын - салу
үшін керекті деректердің барлығын алуға мүмкіндік береді. ’’Класстар
диаграммасы’’ обьектілер абстракциясы және тізімі негізінде құрылады, олар
тізбектер диаграммасында қолданылған қолданушылармен анықталады, ол
итерациялық өзгерістерінен алынады.
Атрибуттарды, әдістерді, қасиеттерді, уақиғаларды, класстарды анықтау.
Класстар диаграммасы – класстар арасындағы байланыс - өзгешелігі және
көрсетілуінің элементтері.
Алгоритмдер және ақпараттардың берілу моделін жобалау әдістемесі.
Пәндік аймақтың сөздігін құру – текстуальды сипаттама, керекті заттарды
белгілеу және олардың идентификациясы, таблицалар – заттар мінездемесі,
оларды қолданудың шарттары. Декомпозиция және құрылымдау әдістері.
Құрылымдық деректерді декомпозициялау үшін реляциялық таблицалардың
қалыптастыру әдістемесі. Графтар және ақпараттық моделдеу үшін тізбекті
және паралельді қолданылуы. Екі жақты графтар – заттар моделі –тәртібі.
Циклдар және екіжақты графтағы шынжырлар. Тәртіп және деректер ағашы,
деректер және ағындар функциялары. Желілік моделдер және фреймдер. Формалар
және панелдер – жоба контейнерлері. Текстік редакторлар. Аспаптық
құралдардың турбо элементтері – өңдеудің жылдамдығы.
Бақылау сұрақтары:
1. ПӨ логикалық жобалау этаптарының құрамының қадамдарын атаңыз?
2. Пәндік аймақты сипаттау кезіндегі қолданылатын әдістер қандай?
3. Логикалық жобалау (ЛЖ) этапында қолданылатын аспаптарды атаңыз(ЛП)?
4. ЛЖ этапында RR қандай диграммаларды құрады?
5. Кооперативті диаграмма мәні?
6. ЛЖ этапының нәтижесі ретінде қандай диаграмма алынады?
Дәріс 4. UML. Өңдеудің функционалдығын сипаттау. Аспаптары мен әдістері. (2
сағ)
UML. Функционалдық өңделуінің сипаттамасы. Аспаптары мен әдістері.
Графикалық және текстік құралдар сипаттамасы және проблемелы аймақты
құжаттау – деректер және функциялар. Жоба құжаттары және құрылым
сипаттамасы және құрамы стандарттармен анықталады. Графикалық сұлбалар және
АТ жоба диаграммалары. Текстілік және графикалық редакторлар – құрамы және
құрылымы, қолданылатын шаблондары және дайындықтары, интерфейстің
ұйымдастырылуы, импорт және экспорт мүмкіндіктері, пайдаланушы құрылысы,
жұмыс режимін құрастыру.
Аспаптар және технологиялармен жұмыс істеу үшін - BP Win, MS Visio, MS
Net және т.б. Программаға қойылатын талаптарды спецификациясы және өңдеудің
функцияналдық мүмкіндіктерін сипаттау үшін қолданылуы. IDEF 0, 3; DFD
стандарттары. Құрылым сипаттамасы және BP Win арқылы процесстердің өтуі.
АЖ құрудың бастапқы этаптарында біз автоматандырғымыз келіп жатқан ұйым
қалай жұмыс істейтіндігін ұғынып алған жөн. Ол ұйымда жұмыс істеушінің бірі
де оны толық білмейді, сол үшін АЖ құрар кезде соны анықтап білу керек.
Ұйым жетекшісі оны толық біледі деуге болады, бірақ ол әрбір жұмысшының
ісін ашып айта алмауы мүмкін. Ал қатардағы жұмысшы өз жұмысына жауапты ол
да басқалар жайында ақпараттарды бірмейді. Сондықтан ұйым жұмысын сипаттау
үшін модел құру керек. Міне BPwin, сол моделді құру үшін керек –
функциональдық модель (немесе процесстер моделі). Әдетте бірінші ұйым
жұмысының қызметтері жайындағы модел құрылады -"AS-IS" (қалай бар, сол
түрде). Функциональдық моделдің талдануы оның кемшіліктерінің орнын, және
жаңа бизнес - процесстің артықшылықтарын, сонымен қатар ұйымның бизнес
құрылымы қандай өзгерістерге ұшырайтындығын толық білуге мүмкіндік береді.
Моделден табылған "AS-IS" кемшіліктерді, "TO-BE" (қандай болуы керек)
моделі арқылы жоюға болады – ұйымдағы бизнес – жоспарлардың жаңа моделі.
Бизнес – жоспарларды моделдеудің ыңғайлы тілі болып IDEF0 табылады, ол 20
жыл бұрын Дугласом Россом (бұрын SADT - Structured Analysis and Design
Technique деп аталған) жасалған. SADT әдістемесі Дэвида А.Марка және
Клемента МакГоуэнаның "Методология структурного анализа и проектирования
SADT" кітабында толық берілген, Метатехнология баспаханасы, 1993.
SADT революция негізінде 60 жылдың аяғында пайда болған. Бұл кезде көпшілік
мамандар бағдарламаның қамсыздандырумен айналысты, көпшілігі басқару және
қаружараққа бақылау жасап телефон байланысында қолданылатын аналогтық
жүйемен бағдарламаның қамсыздандыру, ірі масштабтық жүйені құру және
күрделі тапсырманы шешуге тырысты. Сол кезде ірі масштабты жүйені құрумен
айналысқан мамандықтар үлкен реттелушілік керек екенін мойындады. Бұл түрде
өңдеушілер жүйені құру процесін өңдеп оны келесі фазаларға бөлді:
- анализ – жүйенің жұмысының анықтамасы.
- жобалау – жүйелерді және өзара әрекетін анықтау.
- реализация жүйені бөлек-бөлек өңдеу бірігу – бір бүтінге жүйенің
бірігуі.
- Тестлеу – тексерісі
- Құрылғы – жүйенің әрекетке енгізілуі.
- Функциялау – жүйенің қолданылуы.
Бұл сәйкестілік әрқашан итерациялық орындалған себебі жүйе толықтай
қолданушылардың қажетін қанағаттандырмады.
Сонымен қатар бұл модельмен бағытталынған жүйенің басқаруында әрқашан
қиындықтар туып отырады. Жүйенің берілуінен соң туындаған эксплуатациялық
шығындар құрылған жүйенің шығыны ретінде жедел жылдамдықта өсе бастады.
Кейбіреулері жүйені құру кезінде пайда болған қателіктерге тиісті
эксплуатациялық шығындар өсті деп санайды. Зерттеу бойынша жүйедегі
қателіктердің көпшілік проценті анализ және жобалау процесінде пайда болды.
Мысалы, жобалау стадиясының қателіктерін түзету екі есе тұрады тестлеу
стадиясында он есе, ал жүйенің эксплуатациясында жүз есе қымбат, анализ
стадиясына қарағанда. Қателікті тапқанда шамамен екі есе көп уақыт кетеді,
ал оны түзетуіне шамамен бес есе кетеді. Сонымен қатар қолданушылардың
өзінен анализ қателігі және жобалаудан жиі қателіктер кетіп отырады. Жүйені
құру кезінде бірнеше мәселелер туындады. Бірлік шешім болмады.
Қолданушылардың өңдеу процесіне бақыланбады.Сәйкестілік тексерісі орынды
жүргізіледі және түбегейлі жоқ болады. Бір этаптың нәтижесі екіншісімен
сәйкес келмейді. Процесс қиындықпен бағалауға берілді сапалық және сандық
жағынан. Жүйені құрушылар құрылымдық бағдарламалау типті әдістемесін
қолданғанда және жоғарыдан төмен жобалағанда олар қойылған тапсырманы
шешеді немесе жаман қойылған тапсырманы немесе жақсы қойылған тапсырманы
шешеді. Сонымен қатар жүйені құру кезіндегі қателіктер аппараттық құырылғы
бағдарламалық қамтасыздандыру көмегімен оңай табылып отырады. Жие бұл
қателіктер функцияналды спецификацияны немесе спецификациянымен және
жобалау нәтижесінің арасындағы келіспеушіліктер зерттеліп отырады.
Жобалаушылар жүйенің күрделілігін білді. Жүйенің күределілігі және
көлемінің өсуі өмірлік реалия болып табылады. Бұл алдыңғы сұранысты
қабылдау керек болды. Соңынан тезис пайда болды: анализ әдісінің дұрыстығы,
тиімді тұрысы, өнідірістік және қауіпсіздігі. Кең профильді жүйенің кілттік
мәселесін шешу үшін процестің ертеректі стадиясынан қолданылуы үшін жаңа
әдістер қажет болды. SADT сияқты әдістер қарастырылған мәселелерді дұрыс
түсіну үшін жүйе құрудың бастапқы этапына қажет болды. Ал бұл құруға кеткен
шығындарды қысқартып оның ыңғайлылығын көтереді. SADT – бұл өңдеушілер мен
қолданушылар арасындағы қатынасты жақсартып бастапқы құрылымы үшін
қателіктерді азайту әдісі.
SADT моделінің шынайы және графикалық тілдер қолданылады. Жүйені
жазушы дамдар шынайы тілдің нақты жүйесі қызмет етеді, ал графикалық тілдер
көзіне – SADT әдістемесінің өзі. Әрі қарай сіз SADT графикалық тілі
модельдің шынайы тіліне нақты семантиканы және құрылымды қамтамасыз етеді.
SADT графикалық тілі SADT жүйені жазуға мүмкіндік береді, анықталған және
бір мәнді түрде шынайы тілді ұйымдастырады.
SADT моделі жүйенің функциясына немесе оның объектісіне дайын болады.
Функцияға бағтталған SADT моделін функционалды модель деп атауға
қабылданған, а) жүйе объектісіне бағытталған – мәліметтер модель деп
аталады, функционалды модельдер өзінің ретімен арақатынасын жүйе объектісі
арқылы кескінделеді функция жүйесін бөлшектеу деңгейімен беріледі.
Мәліметтер моделі функционалды моделдерге бағытталған жүйені функциямен
байланысқан жүйе объектісінің жазылуын береді. SADT толық методологиясы
күрделі жүйенің анық жазылуы үшін модельдердіуң көпшілігі құрылуына
мүмкіндік береді. Бұл кітап функционалды модельдер құруы үшін арналған.
SADT мәліметтер моделі көмегімен және көпшілік модельдер құру бұл кітаптың
жиегінен шығады.
SADT блоктары ешқашан диаграммаға кездейсоқ түрде орналаспайды. Диаграмма
авторы оны түсінуі бойынша маңыздылық деңгейінде орналасады. Осыған қатысты
реттіелік SADT-да доминирленген деп аталады. Доминирлену бір блок екінші
диаграмма блогына әсері ретінде түсініледі. Мысалы, диаграмманың ең
доминирленген блогы болып бірінші қажетті сәйкестілік блоктарының функциясы
немесе басқа функцияларға әсер етуші жоспарланған немесе бақылаушы
функциялар болды мүмкін.
Көпшілік доминирленуші блоктары әдетте диаграмманың жоғарғы сол жақ
бұрышында, ал аз доминирленушісі – оң жақ төменгі бұрышында орналасқан.
Нәтижесінде 1,2,3 блоктар үшін 2-1 суретте көрсетілген сатылық схема
алынады.
Беттегі блоктың орналасуы доминирленудің авторлық анықталуын
бейнелейді. Мұндай түрде диаграмма топологиясы қандай функциялар
басқаларына қарағанда әсер ететінін көрсетеді. Бұны белгілеу үшін SADT
аналитигі оның доминирленуі бойынша блоктары кері номерлеуі мүмкін.
Доминирлеу реті әрбір тікбұрыштың оң жақ төменгі бұрышында орналасқан
санмен белгіленеді: 1 көптеген доминирленуді көрсетеді, 2-көпшілігімен
кейінгісін. 2-1 суретте тапсырманы орындау деңгейін анықтау блогы
тапсырманы келесі қадам арқылы бөлшегінің өңделуі қалған барлық қадамдарына
әсер етеді, сондықтан осы блок бірлікпен номерленген.
Жұмыстық орнын дайындау блогы станокта өңдеу және жинау блогынан
бұрын болғандықтан бұл блокқа 3-4 номерлері иеленген.
SADT-да блоктар кері номерленген болуы керек. Блоктар номері жүйелік
функция үшін бірмағыналық болуы қажет және модельдің иерархиясында бұл
функциялар автоматты түрде ұйымдастырады. Блоктар номерін қолдана отырып
және оның әсерін бағалай отырып аналитик функционалды доминирлену принципі
бойынша модель ұйымдастырады. Бұл әрбір функцияның иерархиялық ретіне
келісуге мүмкіндік береді. Сондықтан біз міндетті түрде олардың доминирлену
ретіне сәйкесінше блоктарды номерлеу мүмкіндігін береміз.
SADT диаграммасы бір-бірімен 3-6 дейінгі блоктардан тұрады және модель
құрылымының бірнеше түрлері бар.Бір диаграммасын айыра білу үшін С-
номерлері қолданылады. Диаграммадағы блоктар жүйелік функцияларды
көрсетеді,ал иіні көптеген объектілердің жүйесін көрсетеді.Көп кезде
блоктар диаграммасында домирленген тәртібі бойынша орналасады,яғни бір-
біріне қатысты маңыздылығымен. Блоктармен қосылған иіндер,объектілер
жиынтығын көрсетеді және бірнеше бұтақтарға бөлінеді, әр түрлі күрделі
әдістермен қосылады. Бірақта иіндер барлық бөлінген және қосылған жағдайда,
олар өздеоі көрсетілген объектілерді сақтау керек.
SADT диаграммасы белгіленген объектілер декомпозициясы болып табылады.
Объект блок және оның иіндерімен шектеледі.Шектеуі бар диаграммаларды ата-
аналық диаграмма, ал ата-аналық номерлі декомпозирленген блок, ұрпақ
диаграммасы деп аталады. Ата-аналық диаграммалары және ұрпақ
диаграммаларын С- номерлерімен байланыстырамыз.Осы модель өзінің
актуальдылығын сақтайды.
ICOMкодтары , ұрпақ диаграммамен ата-аналық диаграммаларды қосу үшін
қолданылады.
Түін номері берілген диаграмманың сатысын иерархиялық модельде
идентифицирлейді.
Егер модельде диаграммаларды оқу үшін өте қиын болса, ол үшін техникалық
қабылдағыш иіндердің тоннельге кіруі типін қолдануға болады.
Бағалық талдау
Бағалақ талдау (ABС) кең тараған әдістеме болып табылады, ол халықаралық
корпорациялармен және мемлекеттік ұйымдармен (соның ішінде АҚШ
департаментімен де қолданылады) ұйымдағы нақты шығындарды іздеу үшін
қолданылады. Бағалық талдау есеп беру, шығындардың деректерін жинау,
жұмыспен байланысты шығындарды жинау сияқты талдаулардан тұрады. Осы
талдаулардың арқасында жалпы процесске кететін шығынды талдап шығуға
болады. АBC жұмыс моделіне негізделген, өйткені сандық баға қою мүмкін
емес. ABC арқылы шыққан шығындарды анықтап ұйымды қайта құру кезінде оған
қандай модел қолдану керек екендігін толық анықтауға мүмкіндіктер туады
(Business Process Re-engineering, BPR). Бағалық талдау арқылы келесі
жұмыстарды да жүргізуге болады:
▪ ұйымдық өнімнің нақты бағасын анықтау;
▪ тапсырыс берушіні ұстап тұру үшін бағаны анықтау;
▪ бірінші кезекте көңіл бөлу керек жұмыстарды анықтау және бағасы
қымбат жұмыстарды табу және т.б.
ABC әдістемесі келесі негізгі сипаттамалардан тұрады, шығын объектісі
(жұмыстың орындалу себебі), шығынды жүргізу (кіріс мінездемелері және
жұмысты басқару, оның қанша уақытта және қалай орындалатындығы жайындағы
ақпараттар), және шығын ортасы (шығын статьялары). BPwin-да осы жұмыстардың
барлығына көңіл бөлінген, бағлық талдау жасаудан бұрын қанша ақша кетеді
және қанша уақытта орындалатындығы талданады, одан кейін шығын ортасы
табылады (cost centers). Нәтижесінде, әрбір жұмыс үшін декомпозиция схемасы
бойынша оның істелу ұзақтығы табылады (duration), және жалпы жұмыстың
істелуіне кететін уақыт есептелінеді (frequency) және әрбір шығын ортасына
кететін ақша есептелінеді, яғни әрбір жұмысқа жұсалатын ақшалар шығын
статьясымен беріледі.
MS Visio беттері және олардың қолданылуы. ИТ беттердің шаблоны. Дайын
заттарды қолдану, нәтижені сақтау, өңдеу құжатын алу немесе экспорттау. Net
технологиялары – Sun, MS. Айырмашылықтары мен ұқсастықтары. MS Net құрылымы
– программаларды өңдеудің технологиялық аспаптары.
Олар өңдеудің функциональдық мүмкіндіктерін сипаттау үшін және программаға
қойылатын талаптардың спецификациясы үшін қолданылады. Ақпараттық
обьектілердің логикалық моделін құру әдістемесі. Прототип немесе бос парақ,
элементтер компоновкасы және қосылуы, графиканың текстілік көрсетілілімі,
шығу файлдарының форматы және экспорты.
Бақылау сұрақтары:
1. Қандай сұлбалар бизнес-процессті сипаттайды?
2. IDEF0 және IDEF3 сұлбаларының айырмашылықтары?
3. BPWin –дағы АВС аббревиатурасының мәні?
4. MS Visio –нің қандай аспаптық беттерін ПӨ ЛЖ процессі кезінде
қолдана аламыз?
Дәріс 5. Кластар диаграммасын құру. Әдістері, технологиялары, аспаптары.
(2 сағ)
Класс түсінігі. Класс (Class) ортақ қасиетттері (атрибуттары), тәртібі
(функциялары), семантикасы және басқа объектермен байланысы бар объектер
тобын анықтайды. Класстың объектіні құруға арналған шаблон ретінде қарауға
болады. Әрбір объект қандайда бір ғана кластың нұсқасы мысал ретінде
келесідей сипаттамалары бар ‘курсты ұсыну’ класс анықтамасын қарастырайық :
• Атрибуттар – сабақты өткізетін орын, сабақты өткізетін уақыт,
курстың аталуы, курс нөмірі, ұсыныс нөмірі;
• Функциялары – сабақты өткізетін орынды анықтау, сабақты өткізетін
уақытты анықтау, студентті тіркеу, студентті тіркеуді тоқтату.
Курстық ұсыну класының нұсқасының орнына ‘алгебра 101, 1- бөлім’ және
‘алгебра 101 , 2- бөлім’ объектілерінде алуға болатын еді, себебі олардың
да әр қайсысының нақты атрибуттурының жиынтығы және ортақ функционалдық
сипаттамалары бар.
Дұрыс құрылған класс тек бір ғана абстракцияны бере алады. Мысалы,
студент туралы мәлімет сақталған , сонымен қатар барлық оқу барлығында
студент өткен курстар тізімі функциясы көрсетілген класты сәтті құрылған
деп айта алмаймыз, өйткені ол екі әртүрлі операциялар тобын қамтиды.
Сондықтан мұндай класты екіге – студент және студент өткен курстар
бөлсе жақсы болар еді.
Класстың атауы үшін пән облысына сәйкестендіріліп қабылданған терминдерді
қолданған дұрыс. Класс аты ретінде жобаланатын түсінікті толығымен сипаттай
алатын зат есіміңіз жекеше түрі қолданылады. Кейде қысқартылған атауларда
қолданылып, класты құжаттандырғанда міндетті түрде мағынасын ашып көрсету
керек. Егер аббревиатура бірдей мағыналы емес интерпретация жіберсе, онда
сәйкесінше айтылудың толық түрін қолданамыз. Объектілер мен кластар
арасындағы ерекшелікті табу қиын.
UML–да класс зоналарға бөлінген тіктөртбұрыш түрінде кескінделеді.
Жоғары зонада класс аты , ортасында оның құрылымы (атрибуттар тізімі ) оның
астындағысында тәртібі сипаттамаларын анықтайтын функциялар беріледі.
Класты қалай құрады
1. Browser терезесінің Logіcol Vіew элементіне тышқан сілтеушіні қойып,
конткстік менюді белсенді ету үшін оң батырмасын шертеміз.
2. менюді New--- Class элементтерін таңдау; Browser терезесінде
кескінделген ағаш (бұтақ)жаңа класқа сәйкес келетінNew- Class
элементімен толықтырылады.
3. New-Class элементін таңдап және кластың қажет атауын енгізіп оны
өзгертеміз.
Класстар диаграммасын алу тәртібі. Функциональдық және актерлармен
функциялардың бірлесе қолданылуы. Ақпараттық элементтер және құрылымдар
(АО) арасындағы қарым – қатынас және байланыс. Инкапсуляция, ... жалғасы
Сіз бұл жұмысты біздің қосымшамыз арқылы толығымен тегін көре аласыз.
Тақырып 1. Пән – стандарттары және өңдеу процессі. (4 сағат)
Дәріс №1. Кіріспе. Өңдеу тәртібі. Құжат және мазмұн талаптары. ПӘҚС
даму тарихы. (2 сағ)
Түсініктемелерді анықтау: программа, деңгейлері және категориялары
(бағыттары) программалау, программаны өңдеу және аспаптары. Аспаптар, ол
жұмысты орындау үшін арналған құралдар, яғни программаны өңдеу және тарату
екі топқа бөлінеді аппараттық және программалық. Аппараттық –
микропроцессорлар және қосылатын (сыртқы) құрылғылар. Программалық – олар
жобалау методологиясымен анықталған, барлық жұмыстарды орындауға мүмкіндік
беретін программалар. Беріліп отырған пән негізінен, компьютерге
программаларды орнату және өңдеу үшін қолданылатын программалық аспаптық
құралдарды оқып үйренуге арналған. Программалық өнімді (ПӨ) өңдеу көптеген
бір-бірімен байланысқан әрекеттерден тұрады, олар:
- деректер моделін құру және есептеу әдістемесі;
- есептеуді қамтамасыздандыратын, функциональдық сипаттамасы;
- деректер құрылымын анықтау – компьютерде және алгоритмде көрсетілу
моделі;
- есепті тарату әдістерін сипаттау және анықтау (тестер және шешу
алгоритмі);
- пайдаланушы интерфейсін сипаттау және анықтау;
- ПӨ қолдау құралдарын анықтау;
- есеп спецификациясы;
- тестілеу программасын қоса отырып, программа текстін жазу;
- программаның тестіленуі, трансляциясы және жөнделуі;
- қолдау кітапханаларын қосу және байланыстыру;
- орындау ортасын құру; орындамалық модулді орналастыру және жүктеу;
- орнатылған көмекті құру және өңдеуді құжаттау;
- орнатылатын (инсталляциялық) ПӨ пакетін құру.
Rational Unified Process (RUP) аймағында программаларды өңдеуге арналған
әрекеттер жиыны келесі этаптардан тұрады: - талаптарды анықтау; - жобалау;
- программалау; - тестілеу; -ендіру.
Көрсетілген жұмыстарды орындау үшін көптеген программалар жиынтығы үнемі
өңделіп және толықтырылып отырады – ол аспаптар, программаның өңделу
процессін автоматтандыру және қалыптастыру үшін мүмкіндік береді. Бұл
құралдарды қолдану өңдеу және программалық өнімді енгізу уақытын азайтады.
Компьютер үшін программа – бұл программалау тілінде құрылған немесе
жазылған, тәртіптер тізімі. Программалау тілі берілген есепті шешу үшін
және тиімді, жылдам, сапалы, экономды жобалау мақсатында таңдалады.
Тіл деңгейі – программалау деңгейі. Тіл деңгейі – программалау деңгейі.
Төменгідеңгейлі программалау – бұл микропроцессор деректер форматын және
командаларын кодтық немесе мнемоникалық формада (ассемблер) қолданатын
программалау. Проблемалы – бағытталған программалау (текстуальды) – бұл
деректер форматын және командаларын проблемалы – бағытталған тілдерде
программалау. Визуальды программалау – бұл деректер форматын және
командаларын программаларды өңдеудің визуальды құралдары арқылы
программалау.Обьектілік немесе компоненттік программалау әртүрлі
конструктивтерді бірлік элемент ретінде қолдануға мүмкіндік береді.
Командалық (атомарлы), құрылымдық, модульдік программалау –
категориялары, программаларды өңдеу кезінде қолданылатын тілдің типтік
конструкциясымен анықталады. Құрылатын программа үшін, проблемалы аймақ,
программалаудың бағытын анықтайды – ғылыми түрде, бизнес есептерін шешу
үшін, обьектілер мен процесстерді басқару үшін, ақпараттарды көрсету және
басқару үшін, Интернет пен қарым – қатынас жасау үшін, деректер қорымен
қарым – қатынас жасау үшін және т.б. қолданылады.
Құрылымдық программалау концепциясы.
Құрылымдық программалау – программалау методологиясы, жүйелік түрдегі
талдауға негізделген, ПҚ тарату және жобалау. 70 – жылдардың басында пайда
болды және соншалықты өміршең, сондықтан да осы күнге дейін пайдаланылады.
Бұл технологияның негізі келесі тәртіптерден тұрады:
• Қиын есептер кішірек бөліктерге бөлінеді, функциональды түрде негізінен
басқарылатын есептер дұрыс. Әрбір есептің бір кірісі және бір шығысы
болады. Бұл жағдайда программа ағымы көптеген есептер тобынан және
түсінікті функционалдық тағайындамасынан құралады.
• Есепте қолданылатын, басқарылатын құрылымның қарапайымдылығы және
атомарлығы. Бұл, логикалық есеп минималды, функционалды толық қалыптасқан
қарапайым басқарылатын құрылымнан тұруы керек екендігін көрсетеді.
• Программаның өңделуі этап бойынша орындалады. Әрбір этапта шектелген есеп
саны, нақты қойылған тапсырмасымен және есеп барысындағы оның атқаратын
мәнімен, түсінікті қойылымы шешілуі керек. Егер ондай шамаға жетпесе,
онда ол бұл этап өте үлкен және оны тағы басқа қадамдарға бөлу керек
екендігін білдіреді.
Модулдік программалау концепциясы.
Құрылымдық технология сияқты мұнда да, модулдік программалау концепциясын
бірнеше түсініктемелер және тәртіптер түрінде қалыптастыруға болады:
• Есептің функциональдық декомпозициясы – үлкен есепті кіші есептерге бөлу,
олар функциональды өзбектінше орындалатын ішкіесептер - модулдер.
Модулдер өзара кіріс және шығыс деректерімен байланысқан.
• Модуль - модулдік программалау концепциясының негізі. Әрбір модульдің
функциональдық декомпозициясы бір кірісі және бір шығысы бар "қара жәшік"
ретінде қаралады. Модульдік көзқарас программаның модернизациясын
процесстің эксплуатациясы кезінде ешбір қатерсіз орындауға мүмкіндік
береді және оны қолдап отырады. Қосымша модулдік программалау бір жобаның
программасының әртүрлі бөліктерін әртүрлі программалау тілдерінде
орындауға мүмкіндік береді, одан кейін компоновкалау құралдары арқылы
оларды бір жүктемелеу модуліне біріктіреді.
• Таратылатын шешімдер қарапйым және түсінікті болуы керек. Егер модульдің
атқаратын қызметі түсініксіз болса, онда бастапқы немесе аралық
декомпозиция есептері дұрыс, керек еткен дейгейде, сапалы жүрмегендігін
білдіреді. Бұл жағдайда есепті қайта талдау керек, мүмкін, қайта бөлулер
жасау, яғни ішкіесептерге бөлу жұмыстарын орындау керек болады. Жобада
қиын орындалатын орындар кездессе, онда оларды жүйемен ойластырылған
комментарилер арқылы құжаттау керек. Бұл процесс модулдердің жұмысының
толық түсінікті, қызметтері анықталған және байланыстырылғанға дейін
қайталана береді.
• Модулдің барлық айнымалыларның қызметі комментерилердің көмегімен
анықталуы және жазылуы керек.
Объектілі-бағыттылған парадигма.
ОБП идеясы негізінен осы деректерді өңдейтін процедураларды бір бүтін -
обьектіге байланыстыру үшін жасалған. ОБП маңызды үш принцип негізінде
құрылған, олар обьектілерге жаңа қасиеттер береді. Бұл принциптар ретінде
инкапсуляция, мұрагерлену және полиморфизм алынады.
• Инкапсуляция – Осы деректерді өңдеу алгоритмдері мен деректерді бір
бүтінге біріктіру. ОБП деректері көлемінде – объект полесі,
алгоритмдері – объектілік әдістер алынады. Полелер мен алгоритмдер
іштен қолданылады, - жалпы, сырттан немесе тек обьект ішінде – соған
тәуелді, ішкілер немесе байланысқан обьектілер – қорғалған.
• Мұрагерлену – обьектілер қасиеті өздерінің мұрагерлерін туындайды және
оларға өздерінің қасиеттерін үнсіздікпен ұсынады. Объект -
мұрагерленуші, ол қасиеттерді толықтыра алады немесе басқамен оны
ауыстыра (орынбастыра) алады.
• Полиморфизм – туыстық обьектілердің қасиеттері (яғни бір объектіден
тараған бір түбірі бар обьектілер) негізінен бір – біріне ұқсас, мәні
жағынан бірдей проблемаларды әртүрлі әдістермен, оның уақытына және
орналасу ретіне байланысты шешу.
Программаны өңдеу үшін алынған аспап таңдалған деңгей негізімен, бағытымен,
өңдеу категориясымен анықталады және текстуальды немесе визуальды түрде
беріледі. Қазіргі заманғы программалау – компоненттік (объектілік),
уақиғалық және визуальды болып алынады. Түсініктемені анықтайтын болсақ.
Программаны өңдеу мемлекеттік және шетелдік стандартқа сәйкес, өңдеуші
ұсынған технологиялар мен әдістемелер немесе типтік программалар арқылы
орындалады.
Аспаптық құралдардың классификациясы. Өңдеу процессі және таратылуының орны
бойынша, уақытша принципі бойынша, қолданылатын технологиялары мен
әдістемесі бойынша, продукт сапасы бойынша және т.б.
Пән мақсаты мен міндеттері. Силлабуста берілген.
Программаны өңдеу процедурасындағы аспаптық құралдардың орны мен атқаратын
қызметі. Әрбір программаны өңдеу этабының өз аспаптар жиыны бар. Силлабуста
барлық өңдеу қадамдары көрсетілген. Әрбір қадам өңдеу нәтижесімен
анықталады – негізгі құжат болып, және қосымша құжат болып, этапты жабу
алынады. Аспап, сәйкесінше, негізгі немесе қосымша болады.
Сапа мінездемесі және аспапты қолдану. Жазықтықтағы, уақытша, тұрақты,
берік, қазіргі заманғы, интуитивті түсініктер, визуальды, статикалық және
динамикалық, өңдеуді түзету және өзгертуді қамтамасыздандыру, нәтижеге
байланысты, сәйкес стандарттар мен технологиялар, мақсатың орындалуымен
және т.б.
Аспаптық құралдардың дамуына қысқаша түсініктеме. Этаптар 1960 – 1975 –
1985 – 2000 жылдар. Тілдер, компиляторлар, компоновщиктер, құрастырушылар,
жүктемелегіштер, операциялық жүйелер, өңдеу құралдары және тестілеу,
енгізу құралдары және программаны қолдау. Соңғы 20 жыл ішіндегі
программалау тілдерінің даму схемасы.
Бақылау сұрақтары:
1. Программа дегеніміз не?
2. Аспап дегеніміз не?
3. Программалаудың деңгейлері мен категорияларын атаңыз?
Дәріс №2. Мемлекеттік және шетелдік стандарт құжаттары, өңдеу құрамын
анықтау. RUP. (2 сағ)
Жобалау әдістер және программаның өміршендік циклын қамтамасыздандыру.
Командалық және жеке жобалау және оған керекті аспаптар. Текстуальды және
визуальды жобалау – технологиялары және әдістемесі, қолданатын аспаптары.
Визуалды модельдеу дегеніміз не? Визуальды модельдеу (vіsual modelіng) –
нақты өмірдің объектілері мен ұғымдарын көрсететін және өзі көрініс табатын
абстракциялардың көмегімен проблемаларды қабылдау әдісі. Модельдеу
проблемаларын талдау, барлық қызығушылығы бар жақтар арасында ақпараттардың
алмасуы (қолданушылар, пәндік аумақтағы мамандар, аналитиктер, дизайнерлер
және т.б.), программалық қолданбалар мен мәліметтер базасын жобалау, және
документацияны дайындау үшін пайдалы құрал болып табылады. Модельдеу
талаптарын жақсы қабылдауға, жүйенің дизайн сапасын жақсартуға және оны
басқару деңгейін жоғарылатуға өз септігін тигізеді. UML – объекті
бағдарланған жүйелермен құрастырылатын мәндердің документациясын белгілеу
мен көріністендіру үшін қолданылатын тіл.
Модельдің көмегімен біз керегі жоқ детальдарды қарастырмай-ақ бар
назарымызды негізгіге аудара отырып, проблеманы оңайлатуымыз мүмкін.
Абстракциялау мүмкіндігі – күрделік феноменін шешуге көмектесетін, адам
интеллектісінің іргелі қасиеті. Мыңдаған жылдар барысында суретшілер, қол
өнершілер және құрылысшылар нақты шығармашлық ойларды жүзеге асыру алдында
түрлі модельдерді жобалау талпыныстарын жасаған. Бұл құбылыстар
программалық қамтаманы жасау индустриясын айналып өткен жоқ. Күрделі
программалық жүйені құрастыру үшін, автор оның қасиеттерін түрлі
көзқарастар тарапынан абстракциялауға, белгілеулердің нақты жүйелерінің
көмегімен модельдерді жобалауға, олардың бастапқы талаптарға сәйкестігін
тексеріп алуға міндетті, тек содан кейін ғана жүйені жаңа функциялармен
толықтыра отырып, модельді практикада жүзеге асыруға болады.
12207 стандарты – Программалық жүйенің өміршендік циклының процесстері
(ПЖ ӨЦ). Есептерді, жұмыстарды, процесстерді анықтайды. Кімге
тағайындалғанын зерттейді. Нақты адаптация және шектеулер. Нормативті
сілтемелер. Анықтамалар. Стандарттың қолданбалы қолдану – 5 негізгі, 8
қосымша, 4 ұйымдастыру процесстері. Өңдеу программасы – талаптардың
талдануы, жобалау, программалау, жинау, тестілеу, орындау үшін енгізу,
қабылдау. Этап бойынша жұмыстар тізімі. Этап бойынша жұмыстар мазмұны.
Аспаптары.
Қазіріг заманғы аспаптық құралдар. Барлық өңдеу этаптарын
визуализациялау. Визуальды технологиялар негізі. Өңдеу ортасы, обьектілер,
компоненттер кітапханасы. Аспаптар дайындау фирмаларының талдануы.
Талданудың интерфейстік құрамы. Интерфейс стандарттары. Қазіргі заманғы
визуальды аспатардың құрамы. Программаларды өңдеу аспаптарының құрамын
жобалаудың бірлік ұстанымдары және олардың әртүрлілігі.
RUP технологиясы, олардың өңдеу құжаттары және фазалары, аспаптары.
Rational Unified Process Бүгінгі күнде ол ең көп кездесетін
әдістемелердің бірі. Ол Rational Software копаниясымен өз өнімдерін қолдау
үшін шығарылған, олар оннан көп деп есептелінеді (ең көп кездесетін
өнімдеріне - Rational Rose және Requisite Proжатады). RUP үш атақты
адамдармен құрылған - бұлар Гради Буч, Ивар Якобсон және Джеймс Рамбо
(Rumbaugh). Олардың барлығы қиын программалық қамтаманы өндеуде үлкен
жетістіктерге жеткен адамдар, оны RUP бейнесінен – ақ көруге болады. RUP
Итеративтігі, қазіргі заманғы дамыған кез – келген процесс сияқты, ол да
итеративті болып табылады. Бұл яғни, құрылатын жоба бірнеше итерациямен
орындалатындығын көрсетеді. Әрбір итерация аяғында жұмыс жасайтын өнім
версиясын алуға мүмкіндіктер бар, бірақ олардың функционалдығы толық емес.
Одан кейін орындалатын итерацияларда функционалдылық толықтырылып отырады
да, соңында дайын өнім ала аламыз. Итеративті өнім идеясынның процессін
келесі түрде көрсетуге болады (сурет 1, қара).
Сурет. 1.Спиральдің әрбір
бөлігі - итерация. Яғни жүйе
функционалдығы біртіндеп
өсіп отырады.
Итеративті өңдеудің артықшылықтары көп. Релиздердің көп бөлігі өнім
сапасына ықпалын тигізеді, олар әрбір итерация сайын тестіленіп отырады.
Яғни бастапқы тексерулер жүргізілгеннен кейін-ақ пайдаланушы күткен өнімді
алуға мүмкіндіктер бар және өзгертулерді сол кезде енгізуге болады, егер ол
қажет болса. Сонымен - қатар, жобаны жоспарлау да оңай, өйткені бірінші
итерациядан кейін ақ ол түсінікті болады, және жобаны басқарушы келесі
итерацияның аяқталу уақытын да алдын – ала жоспарлауға мүмкіндігі болады.
Айта кететін жағдай, 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 стандарттары және т.б.
Аспаптық құралдарға стандарттардың таратылуы. Өңдеудің визуальды
элементерінің жиынын дайындау. Элементтер кітапханасының құрамын жедел
құрастыру мүмкіндіктері. Жобалаудың жетіспейтін стандартты элементтерін
қосу. Өзгертудің оперативтігі.
Ақпаратты қорғау стандарттары. Р511.88-98. Ақпаратты қорғау. Программалық
құралдарды компьютерлік вирустардың бар жоқтығына тексеру. Р512.41- 98.
Қатынауды басқару, бақылау жүйесі және құралдары. Классификациясы. Жалпы
техникалық талаптар. Тексеру әдістері. Кодтың комбинация мәндері –
санкцияланбаған қатынаудан қорғау тұрақтылығы. Қатынауды басқарудың жабдық
программасы не істеуі керек? Программаның әрекеттерге тұрақтылығы.
Бақылау сұрақтары:
1. Программаны өңдеу процесінің құрамын және тәртібін негізгі қандай ГОСТ-
лар анықтайды?
2. Пәнді оқып үйренуді қалай ұйымдастыруға болады?
3. Программаны өңдеу процесінің этаптары?
4. Жоғарғы деңгей қорғанысындағы кілттер жинына қатынау талаптарын
атаңың?
5. Өңдеу сапасын қамтамасыздандыру мінездемесі қандай?
6. RUP-тағы артефакт дегеніміз не?
7. Программа дегеніміз не?
8. Программалаудың қандай деңгейлері мен бағыттарын білесіз?
9. Аспап дегеніміз не және программаны өңдеу процессі кезінде қандай
аспаптар қолданылады?
10. Утилиттер дегеніміз не және қандай утилиттерді білесіз?
11. ПӨ менюіндегі TOOLS сөзін қалай түсінесіз?
Тақырып 2. Логикалық жобалау. (6 сағат)
Дәріс №3. Талаптарды өңдеу. ТТ. Логикалық жобалау аспаптары мен
әдістері.
Жобалаудың логикалық фазасы – программалық өнімнің алдын-ала өңдеу
фазасы. Менде алты құл бар. Олар ақылды, талпынғыш. Менің білетінімнің
бәрі, солардың арқасы. ... Олардың аттары : қалай және неге, кім, не, қашан
және қайда - логикалық модел құру үшін керекті сұрақтар құрамының
парадигмасы. Пәндік аймақтың талдануының және сипаттамасының - этаптары,
алгоритмдер мен деректер моделінің логикалық құрылуы, олардың байланысы
және пайдаланушыға берілуі. Стандарттар. Техникалық тапсырма (ТТ) –
өңдеуге берілетін талаптардың нәтижесі. ТТ құрамы. Өңдеудің ашылған бар
әдістемесі, және олардың қазіргі заманғы құралдарда қолданылуы мен
элементтері. Өңдеу этаптарын алдын – ала спецификациялау және оның ТТ әсер
етуі. Аспаптар – мүмкіндіктері, технологиялары, жұмыс әдістемесі.
Құрылымдық, модульдік және обьектілік ұстанымдар – айырмашылықтары мен
ұқсастықтары. Итерация, комбинирлеу және жоғарыдан – төмен немесе төменнен
– жоғары жобалау.
UML талдау мен жобалау үрдістерінің құрамдас бөліктерін – семантикалық
модельдер, синтаксикалық нотация мен диаграмманы, стандартизациялаудың
сәтті талпынысы.
UML диаграммалары және класстар диграммасын құру тізбегі. Rational Rose
– UML әдістемесін тарату аспабы. Ұқсас есептерді шешу үшін қолданылатын
басқа да визуальды аспаптар. Өңдеу функциянальдығын сипаттау – қолдану
варианттар диаграммасы (талаптар және шектеулер), функция орындалу реттері
– әрекеттердің тізбектер диаграммасы (талаптар және шектеулер), өңдеу
элементерінің бір-бірімен байланыс және бар болу сипаттамасы – кооперативті
диаграммалар (талаптар және шектеулер). Интерфейсті жобалау. Обьектілік
жобаның өңделуі, ОМ 6 қосымшасына сәйкес, негізінен прецеденттер
диаграммасы (ПД) немесе, екінші аталуы – ''Қолдану варианттар
диаграммасы'' (ҚВД) басталады. Диаграмма прецедент барлық қалған жоба
диграммалары үшін арналып жасалады. Ал оның екінші аталуы, негізінен, оның
атқаратын рольін толық көрсетеді деп айтуға болады – пайдаланушы жүйесінің
қолдану варианттар диаграммасы (актерлар, әрекет жасаушы обьект). Сонымен
бұл диаграмма негізінен, егер бұл ұстанымды Коуда (Сoad) атымен беріп
орындайтын болсақ, онда жобалаушы сұрақтарына жауап ретінде - кім, қашан
және не істегендігін білуге болады. Келесі диаграмма – ''Тізбек
диаграммасы'' – Қ.В. (жеке қолдану вариантын орындау) орындауды жеке
түсіндіреді (Қ.В.). Бұл диаграммада, егер Коуда әдістемесін қолданатын
болсақ, онда актер вариантты орындау кезінде кіммен (немен)
байланысқандығы көрсетіледі. Бұл диаграммада Қ.В. орындау уақыты
анықталады, ол жүйеге нақты уақыт (RTS) жүйесінің қалай қызмет
көрсететіндігін көрсетеді және жүйе, ON-LINE типінде, реакцияны шектеумен
ерекшеленетіндігін де көрсетеді. Бұл диаграммада вариантты қолданушылардың
арасындағы өтулер қолданушы әрекетімен анықталады. Сонымен қолданылатын
Қ.В. обьектіге кандидат (немесе обьект атрибуты) болып табылады, ал ол
орындайтын әрекет – обьектінің әдісінің кандидаты болып табылады.
Сондықтан, диаграмма обьектілерді анықтаудың негізі болып табылатындығын
айтып кетуге болады. Бұл диаграммада қолданушылар ретінде интерфейстің
қолданылып отырған элементтерін және басқа ақпараттық обьектілерді алуға
болады.
Объект нақты немесе абстрактылы мән ретінде болады.
Объект дегеніміз – программалық қосымшада нақты бір шекаралар , мағыналар
және мәндермен берілген түсінік немесе абстракция.
Жүйенің әрбір объектісінің үш сипаттамасы болады-
жағдайы, тәртібі және біркелкілік белгісі. Объект жағдайы атрибуттар
–касиеттернінің жиынтығы және басқа абстракциямен байланыс арқылы
анықталады. Мінез-құлық сипаттамасы объектінің функционалдық өмірін қамтуы,
басқа объектер сұранысына әсерін зерттеп және операциялар жиыны түрінде
іске асырылады. Біркелкілік белгісі объектінің әмбебаптығын анықтайды –
басқа объектілермен бірдей болған жағдайда даклас объетілер тобын ортақ
(атрибуттар) , қасиеттер , мінез-құлық(функционалдар), семантика және басқа
объектілер мен байланыс арқылы анықтайды. Класты басқаша объектні құруға
арналған шаблон деп те атауға болады. Әрбір объект тек бір кластың данасы
болып табылады. Класты құрған кезде оны құжаттандыру керек. Сипаттама класс
құрылымын емес, оның мәнін беру керек.
Ratіonal Rose өнімдерінің сериясы құрастырушыны нақты уақыт жүйелерінде
және клиентсервер орталарында қолдануға жарайтын және қазіргі кездегі
бизнес талаптарын қанағаттандыратын тиімді де сенімді шешімдерді қабылдауға
көмектесетін визуалдық модельдеудің толық құралдар жиынымен қамтамасыз
етеді. Ratіonal Rose құралдары біркелкі стандарттарға негізделген және
модельдеуді, оларға жақын сфералардағы бизнес-процестерді оптимизациялауға
талаптанатын, компьютерлік ғылымдармен онша таныс емес тұлғалармен қатар,
программалық қолданбалардың логикасын модельдеу құралдарын қажет ететін
мамандар үшін оңай етеді.
Келесі қолданылатын RR – мен берілген диаграммаларға, - кооперативтік
диаграммаларды жатқызуға болады, - олпар негізінен тәртіп детализациясы
үшін қолданылады, олар уақиғалар аймағын және олардың арасындағы байланысты
анықтайды, қосымша қолданушыларды анықтайды, олардың жалпы және
мінездемелік анықталарын береді – яғни соңғы Класстар диаграммасын - салу
үшін керекті деректердің барлығын алуға мүмкіндік береді. ’’Класстар
диаграммасы’’ обьектілер абстракциясы және тізімі негізінде құрылады, олар
тізбектер диаграммасында қолданылған қолданушылармен анықталады, ол
итерациялық өзгерістерінен алынады.
Атрибуттарды, әдістерді, қасиеттерді, уақиғаларды, класстарды анықтау.
Класстар диаграммасы – класстар арасындағы байланыс - өзгешелігі және
көрсетілуінің элементтері.
Алгоритмдер және ақпараттардың берілу моделін жобалау әдістемесі.
Пәндік аймақтың сөздігін құру – текстуальды сипаттама, керекті заттарды
белгілеу және олардың идентификациясы, таблицалар – заттар мінездемесі,
оларды қолданудың шарттары. Декомпозиция және құрылымдау әдістері.
Құрылымдық деректерді декомпозициялау үшін реляциялық таблицалардың
қалыптастыру әдістемесі. Графтар және ақпараттық моделдеу үшін тізбекті
және паралельді қолданылуы. Екі жақты графтар – заттар моделі –тәртібі.
Циклдар және екіжақты графтағы шынжырлар. Тәртіп және деректер ағашы,
деректер және ағындар функциялары. Желілік моделдер және фреймдер. Формалар
және панелдер – жоба контейнерлері. Текстік редакторлар. Аспаптық
құралдардың турбо элементтері – өңдеудің жылдамдығы.
Бақылау сұрақтары:
1. ПӨ логикалық жобалау этаптарының құрамының қадамдарын атаңыз?
2. Пәндік аймақты сипаттау кезіндегі қолданылатын әдістер қандай?
3. Логикалық жобалау (ЛЖ) этапында қолданылатын аспаптарды атаңыз(ЛП)?
4. ЛЖ этапында RR қандай диграммаларды құрады?
5. Кооперативті диаграмма мәні?
6. ЛЖ этапының нәтижесі ретінде қандай диаграмма алынады?
Дәріс 4. UML. Өңдеудің функционалдығын сипаттау. Аспаптары мен әдістері. (2
сағ)
UML. Функционалдық өңделуінің сипаттамасы. Аспаптары мен әдістері.
Графикалық және текстік құралдар сипаттамасы және проблемелы аймақты
құжаттау – деректер және функциялар. Жоба құжаттары және құрылым
сипаттамасы және құрамы стандарттармен анықталады. Графикалық сұлбалар және
АТ жоба диаграммалары. Текстілік және графикалық редакторлар – құрамы және
құрылымы, қолданылатын шаблондары және дайындықтары, интерфейстің
ұйымдастырылуы, импорт және экспорт мүмкіндіктері, пайдаланушы құрылысы,
жұмыс режимін құрастыру.
Аспаптар және технологиялармен жұмыс істеу үшін - BP Win, MS Visio, MS
Net және т.б. Программаға қойылатын талаптарды спецификациясы және өңдеудің
функцияналдық мүмкіндіктерін сипаттау үшін қолданылуы. IDEF 0, 3; DFD
стандарттары. Құрылым сипаттамасы және BP Win арқылы процесстердің өтуі.
АЖ құрудың бастапқы этаптарында біз автоматандырғымыз келіп жатқан ұйым
қалай жұмыс істейтіндігін ұғынып алған жөн. Ол ұйымда жұмыс істеушінің бірі
де оны толық білмейді, сол үшін АЖ құрар кезде соны анықтап білу керек.
Ұйым жетекшісі оны толық біледі деуге болады, бірақ ол әрбір жұмысшының
ісін ашып айта алмауы мүмкін. Ал қатардағы жұмысшы өз жұмысына жауапты ол
да басқалар жайында ақпараттарды бірмейді. Сондықтан ұйым жұмысын сипаттау
үшін модел құру керек. Міне BPwin, сол моделді құру үшін керек –
функциональдық модель (немесе процесстер моделі). Әдетте бірінші ұйым
жұмысының қызметтері жайындағы модел құрылады -"AS-IS" (қалай бар, сол
түрде). Функциональдық моделдің талдануы оның кемшіліктерінің орнын, және
жаңа бизнес - процесстің артықшылықтарын, сонымен қатар ұйымның бизнес
құрылымы қандай өзгерістерге ұшырайтындығын толық білуге мүмкіндік береді.
Моделден табылған "AS-IS" кемшіліктерді, "TO-BE" (қандай болуы керек)
моделі арқылы жоюға болады – ұйымдағы бизнес – жоспарлардың жаңа моделі.
Бизнес – жоспарларды моделдеудің ыңғайлы тілі болып IDEF0 табылады, ол 20
жыл бұрын Дугласом Россом (бұрын SADT - Structured Analysis and Design
Technique деп аталған) жасалған. SADT әдістемесі Дэвида А.Марка және
Клемента МакГоуэнаның "Методология структурного анализа и проектирования
SADT" кітабында толық берілген, Метатехнология баспаханасы, 1993.
SADT революция негізінде 60 жылдың аяғында пайда болған. Бұл кезде көпшілік
мамандар бағдарламаның қамсыздандырумен айналысты, көпшілігі басқару және
қаружараққа бақылау жасап телефон байланысында қолданылатын аналогтық
жүйемен бағдарламаның қамсыздандыру, ірі масштабтық жүйені құру және
күрделі тапсырманы шешуге тырысты. Сол кезде ірі масштабты жүйені құрумен
айналысқан мамандықтар үлкен реттелушілік керек екенін мойындады. Бұл түрде
өңдеушілер жүйені құру процесін өңдеп оны келесі фазаларға бөлді:
- анализ – жүйенің жұмысының анықтамасы.
- жобалау – жүйелерді және өзара әрекетін анықтау.
- реализация жүйені бөлек-бөлек өңдеу бірігу – бір бүтінге жүйенің
бірігуі.
- Тестлеу – тексерісі
- Құрылғы – жүйенің әрекетке енгізілуі.
- Функциялау – жүйенің қолданылуы.
Бұл сәйкестілік әрқашан итерациялық орындалған себебі жүйе толықтай
қолданушылардың қажетін қанағаттандырмады.
Сонымен қатар бұл модельмен бағытталынған жүйенің басқаруында әрқашан
қиындықтар туып отырады. Жүйенің берілуінен соң туындаған эксплуатациялық
шығындар құрылған жүйенің шығыны ретінде жедел жылдамдықта өсе бастады.
Кейбіреулері жүйені құру кезінде пайда болған қателіктерге тиісті
эксплуатациялық шығындар өсті деп санайды. Зерттеу бойынша жүйедегі
қателіктердің көпшілік проценті анализ және жобалау процесінде пайда болды.
Мысалы, жобалау стадиясының қателіктерін түзету екі есе тұрады тестлеу
стадиясында он есе, ал жүйенің эксплуатациясында жүз есе қымбат, анализ
стадиясына қарағанда. Қателікті тапқанда шамамен екі есе көп уақыт кетеді,
ал оны түзетуіне шамамен бес есе кетеді. Сонымен қатар қолданушылардың
өзінен анализ қателігі және жобалаудан жиі қателіктер кетіп отырады. Жүйені
құру кезінде бірнеше мәселелер туындады. Бірлік шешім болмады.
Қолданушылардың өңдеу процесіне бақыланбады.Сәйкестілік тексерісі орынды
жүргізіледі және түбегейлі жоқ болады. Бір этаптың нәтижесі екіншісімен
сәйкес келмейді. Процесс қиындықпен бағалауға берілді сапалық және сандық
жағынан. Жүйені құрушылар құрылымдық бағдарламалау типті әдістемесін
қолданғанда және жоғарыдан төмен жобалағанда олар қойылған тапсырманы
шешеді немесе жаман қойылған тапсырманы немесе жақсы қойылған тапсырманы
шешеді. Сонымен қатар жүйені құру кезіндегі қателіктер аппараттық құырылғы
бағдарламалық қамтасыздандыру көмегімен оңай табылып отырады. Жие бұл
қателіктер функцияналды спецификацияны немесе спецификациянымен және
жобалау нәтижесінің арасындағы келіспеушіліктер зерттеліп отырады.
Жобалаушылар жүйенің күрделілігін білді. Жүйенің күределілігі және
көлемінің өсуі өмірлік реалия болып табылады. Бұл алдыңғы сұранысты
қабылдау керек болды. Соңынан тезис пайда болды: анализ әдісінің дұрыстығы,
тиімді тұрысы, өнідірістік және қауіпсіздігі. Кең профильді жүйенің кілттік
мәселесін шешу үшін процестің ертеректі стадиясынан қолданылуы үшін жаңа
әдістер қажет болды. SADT сияқты әдістер қарастырылған мәселелерді дұрыс
түсіну үшін жүйе құрудың бастапқы этапына қажет болды. Ал бұл құруға кеткен
шығындарды қысқартып оның ыңғайлылығын көтереді. SADT – бұл өңдеушілер мен
қолданушылар арасындағы қатынасты жақсартып бастапқы құрылымы үшін
қателіктерді азайту әдісі.
SADT моделінің шынайы және графикалық тілдер қолданылады. Жүйені
жазушы дамдар шынайы тілдің нақты жүйесі қызмет етеді, ал графикалық тілдер
көзіне – SADT әдістемесінің өзі. Әрі қарай сіз SADT графикалық тілі
модельдің шынайы тіліне нақты семантиканы және құрылымды қамтамасыз етеді.
SADT графикалық тілі SADT жүйені жазуға мүмкіндік береді, анықталған және
бір мәнді түрде шынайы тілді ұйымдастырады.
SADT моделі жүйенің функциясына немесе оның объектісіне дайын болады.
Функцияға бағтталған SADT моделін функционалды модель деп атауға
қабылданған, а) жүйе объектісіне бағытталған – мәліметтер модель деп
аталады, функционалды модельдер өзінің ретімен арақатынасын жүйе объектісі
арқылы кескінделеді функция жүйесін бөлшектеу деңгейімен беріледі.
Мәліметтер моделі функционалды моделдерге бағытталған жүйені функциямен
байланысқан жүйе объектісінің жазылуын береді. SADT толық методологиясы
күрделі жүйенің анық жазылуы үшін модельдердіуң көпшілігі құрылуына
мүмкіндік береді. Бұл кітап функционалды модельдер құруы үшін арналған.
SADT мәліметтер моделі көмегімен және көпшілік модельдер құру бұл кітаптың
жиегінен шығады.
SADT блоктары ешқашан диаграммаға кездейсоқ түрде орналаспайды. Диаграмма
авторы оны түсінуі бойынша маңыздылық деңгейінде орналасады. Осыған қатысты
реттіелік SADT-да доминирленген деп аталады. Доминирлену бір блок екінші
диаграмма блогына әсері ретінде түсініледі. Мысалы, диаграмманың ең
доминирленген блогы болып бірінші қажетті сәйкестілік блоктарының функциясы
немесе басқа функцияларға әсер етуші жоспарланған немесе бақылаушы
функциялар болды мүмкін.
Көпшілік доминирленуші блоктары әдетте диаграмманың жоғарғы сол жақ
бұрышында, ал аз доминирленушісі – оң жақ төменгі бұрышында орналасқан.
Нәтижесінде 1,2,3 блоктар үшін 2-1 суретте көрсетілген сатылық схема
алынады.
Беттегі блоктың орналасуы доминирленудің авторлық анықталуын
бейнелейді. Мұндай түрде диаграмма топологиясы қандай функциялар
басқаларына қарағанда әсер ететінін көрсетеді. Бұны белгілеу үшін SADT
аналитигі оның доминирленуі бойынша блоктары кері номерлеуі мүмкін.
Доминирлеу реті әрбір тікбұрыштың оң жақ төменгі бұрышында орналасқан
санмен белгіленеді: 1 көптеген доминирленуді көрсетеді, 2-көпшілігімен
кейінгісін. 2-1 суретте тапсырманы орындау деңгейін анықтау блогы
тапсырманы келесі қадам арқылы бөлшегінің өңделуі қалған барлық қадамдарына
әсер етеді, сондықтан осы блок бірлікпен номерленген.
Жұмыстық орнын дайындау блогы станокта өңдеу және жинау блогынан
бұрын болғандықтан бұл блокқа 3-4 номерлері иеленген.
SADT-да блоктар кері номерленген болуы керек. Блоктар номері жүйелік
функция үшін бірмағыналық болуы қажет және модельдің иерархиясында бұл
функциялар автоматты түрде ұйымдастырады. Блоктар номерін қолдана отырып
және оның әсерін бағалай отырып аналитик функционалды доминирлену принципі
бойынша модель ұйымдастырады. Бұл әрбір функцияның иерархиялық ретіне
келісуге мүмкіндік береді. Сондықтан біз міндетті түрде олардың доминирлену
ретіне сәйкесінше блоктарды номерлеу мүмкіндігін береміз.
SADT диаграммасы бір-бірімен 3-6 дейінгі блоктардан тұрады және модель
құрылымының бірнеше түрлері бар.Бір диаграммасын айыра білу үшін С-
номерлері қолданылады. Диаграммадағы блоктар жүйелік функцияларды
көрсетеді,ал иіні көптеген объектілердің жүйесін көрсетеді.Көп кезде
блоктар диаграммасында домирленген тәртібі бойынша орналасады,яғни бір-
біріне қатысты маңыздылығымен. Блоктармен қосылған иіндер,объектілер
жиынтығын көрсетеді және бірнеше бұтақтарға бөлінеді, әр түрлі күрделі
әдістермен қосылады. Бірақта иіндер барлық бөлінген және қосылған жағдайда,
олар өздеоі көрсетілген объектілерді сақтау керек.
SADT диаграммасы белгіленген объектілер декомпозициясы болып табылады.
Объект блок және оның иіндерімен шектеледі.Шектеуі бар диаграммаларды ата-
аналық диаграмма, ал ата-аналық номерлі декомпозирленген блок, ұрпақ
диаграммасы деп аталады. Ата-аналық диаграммалары және ұрпақ
диаграммаларын С- номерлерімен байланыстырамыз.Осы модель өзінің
актуальдылығын сақтайды.
ICOMкодтары , ұрпақ диаграммамен ата-аналық диаграммаларды қосу үшін
қолданылады.
Түін номері берілген диаграмманың сатысын иерархиялық модельде
идентифицирлейді.
Егер модельде диаграммаларды оқу үшін өте қиын болса, ол үшін техникалық
қабылдағыш иіндердің тоннельге кіруі типін қолдануға болады.
Бағалық талдау
Бағалақ талдау (ABС) кең тараған әдістеме болып табылады, ол халықаралық
корпорациялармен және мемлекеттік ұйымдармен (соның ішінде АҚШ
департаментімен де қолданылады) ұйымдағы нақты шығындарды іздеу үшін
қолданылады. Бағалық талдау есеп беру, шығындардың деректерін жинау,
жұмыспен байланысты шығындарды жинау сияқты талдаулардан тұрады. Осы
талдаулардың арқасында жалпы процесске кететін шығынды талдап шығуға
болады. АBC жұмыс моделіне негізделген, өйткені сандық баға қою мүмкін
емес. ABC арқылы шыққан шығындарды анықтап ұйымды қайта құру кезінде оған
қандай модел қолдану керек екендігін толық анықтауға мүмкіндіктер туады
(Business Process Re-engineering, BPR). Бағалық талдау арқылы келесі
жұмыстарды да жүргізуге болады:
▪ ұйымдық өнімнің нақты бағасын анықтау;
▪ тапсырыс берушіні ұстап тұру үшін бағаны анықтау;
▪ бірінші кезекте көңіл бөлу керек жұмыстарды анықтау және бағасы
қымбат жұмыстарды табу және т.б.
ABC әдістемесі келесі негізгі сипаттамалардан тұрады, шығын объектісі
(жұмыстың орындалу себебі), шығынды жүргізу (кіріс мінездемелері және
жұмысты басқару, оның қанша уақытта және қалай орындалатындығы жайындағы
ақпараттар), және шығын ортасы (шығын статьялары). BPwin-да осы жұмыстардың
барлығына көңіл бөлінген, бағлық талдау жасаудан бұрын қанша ақша кетеді
және қанша уақытта орындалатындығы талданады, одан кейін шығын ортасы
табылады (cost centers). Нәтижесінде, әрбір жұмыс үшін декомпозиция схемасы
бойынша оның істелу ұзақтығы табылады (duration), және жалпы жұмыстың
істелуіне кететін уақыт есептелінеді (frequency) және әрбір шығын ортасына
кететін ақша есептелінеді, яғни әрбір жұмысқа жұсалатын ақшалар шығын
статьясымен беріледі.
MS Visio беттері және олардың қолданылуы. ИТ беттердің шаблоны. Дайын
заттарды қолдану, нәтижені сақтау, өңдеу құжатын алу немесе экспорттау. Net
технологиялары – Sun, MS. Айырмашылықтары мен ұқсастықтары. MS Net құрылымы
– программаларды өңдеудің технологиялық аспаптары.
Олар өңдеудің функциональдық мүмкіндіктерін сипаттау үшін және программаға
қойылатын талаптардың спецификациясы үшін қолданылады. Ақпараттық
обьектілердің логикалық моделін құру әдістемесі. Прототип немесе бос парақ,
элементтер компоновкасы және қосылуы, графиканың текстілік көрсетілілімі,
шығу файлдарының форматы және экспорты.
Бақылау сұрақтары:
1. Қандай сұлбалар бизнес-процессті сипаттайды?
2. IDEF0 және IDEF3 сұлбаларының айырмашылықтары?
3. BPWin –дағы АВС аббревиатурасының мәні?
4. MS Visio –нің қандай аспаптық беттерін ПӨ ЛЖ процессі кезінде
қолдана аламыз?
Дәріс 5. Кластар диаграммасын құру. Әдістері, технологиялары, аспаптары.
(2 сағ)
Класс түсінігі. Класс (Class) ортақ қасиетттері (атрибуттары), тәртібі
(функциялары), семантикасы және басқа объектермен байланысы бар объектер
тобын анықтайды. Класстың объектіні құруға арналған шаблон ретінде қарауға
болады. Әрбір объект қандайда бір ғана кластың нұсқасы мысал ретінде
келесідей сипаттамалары бар ‘курсты ұсыну’ класс анықтамасын қарастырайық :
• Атрибуттар – сабақты өткізетін орын, сабақты өткізетін уақыт,
курстың аталуы, курс нөмірі, ұсыныс нөмірі;
• Функциялары – сабақты өткізетін орынды анықтау, сабақты өткізетін
уақытты анықтау, студентті тіркеу, студентті тіркеуді тоқтату.
Курстық ұсыну класының нұсқасының орнына ‘алгебра 101, 1- бөлім’ және
‘алгебра 101 , 2- бөлім’ объектілерінде алуға болатын еді, себебі олардың
да әр қайсысының нақты атрибуттурының жиынтығы және ортақ функционалдық
сипаттамалары бар.
Дұрыс құрылған класс тек бір ғана абстракцияны бере алады. Мысалы,
студент туралы мәлімет сақталған , сонымен қатар барлық оқу барлығында
студент өткен курстар тізімі функциясы көрсетілген класты сәтті құрылған
деп айта алмаймыз, өйткені ол екі әртүрлі операциялар тобын қамтиды.
Сондықтан мұндай класты екіге – студент және студент өткен курстар
бөлсе жақсы болар еді.
Класстың атауы үшін пән облысына сәйкестендіріліп қабылданған терминдерді
қолданған дұрыс. Класс аты ретінде жобаланатын түсінікті толығымен сипаттай
алатын зат есіміңіз жекеше түрі қолданылады. Кейде қысқартылған атауларда
қолданылып, класты құжаттандырғанда міндетті түрде мағынасын ашып көрсету
керек. Егер аббревиатура бірдей мағыналы емес интерпретация жіберсе, онда
сәйкесінше айтылудың толық түрін қолданамыз. Объектілер мен кластар
арасындағы ерекшелікті табу қиын.
UML–да класс зоналарға бөлінген тіктөртбұрыш түрінде кескінделеді.
Жоғары зонада класс аты , ортасында оның құрылымы (атрибуттар тізімі ) оның
астындағысында тәртібі сипаттамаларын анықтайтын функциялар беріледі.
Класты қалай құрады
1. Browser терезесінің Logіcol Vіew элементіне тышқан сілтеушіні қойып,
конткстік менюді белсенді ету үшін оң батырмасын шертеміз.
2. менюді New--- Class элементтерін таңдау; Browser терезесінде
кескінделген ағаш (бұтақ)жаңа класқа сәйкес келетінNew- Class
элементімен толықтырылады.
3. New-Class элементін таңдап және кластың қажет атауын енгізіп оны
өзгертеміз.
Класстар диаграммасын алу тәртібі. Функциональдық және актерлармен
функциялардың бірлесе қолданылуы. Ақпараттық элементтер және құрылымдар
(АО) арасындағы қарым – қатынас және байланыс. Инкапсуляция, ... жалғасы
Сіз бұл жұмысты біздің қосымшамыз арқылы толығымен тегін көре аласыз.
Ұқсас жұмыстар
Пәндер
- Іс жүргізу
- Автоматтандыру, Техника
- Алғашқы әскери дайындық
- Астрономия
- Ауыл шаруашылығы
- Банк ісі
- Бизнесті бағалау
- Биология
- Бухгалтерлік іс
- Валеология
- Ветеринария
- География
- Геология, Геофизика, Геодезия
- Дін
- Ет, сүт, шарап өнімдері
- Жалпы тарих
- Жер кадастрі, Жылжымайтын мүлік
- Журналистика
- Информатика
- Кеден ісі
- Маркетинг
- Математика, Геометрия
- Медицина
- Мемлекеттік басқару
- Менеджмент
- Мұнай, Газ
- Мұрағат ісі
- Мәдениеттану
- ОБЖ (Основы безопасности жизнедеятельности)
- Педагогика
- Полиграфия
- Психология
- Салық
- Саясаттану
- Сақтандыру
- Сертификаттау, стандарттау
- Социология, Демография
- Спорт
- Статистика
- Тілтану, Филология
- Тарихи тұлғалар
- Тау-кен ісі
- Транспорт
- Туризм
- Физика
- Философия
- Халықаралық қатынастар
- Химия
- Экология, Қоршаған ортаны қорғау
- Экономика
- Экономикалық география
- Электротехника
- Қазақстан тарихы
- Қаржы
- Құрылыс
- Құқық, Криминалистика
- Әдебиет
- Өнер, музыка
- Өнеркәсіп, Өндіріс
Қазақ тілінде жазылған рефераттар, курстық жұмыстар, дипломдық жұмыстар бойынша біздің қор #1 болып табылады.
Ақпарат
Қосымша
Email: info@stud.kz