O’zbekiston respublikasi axborot texnologiyalari va kommunikasiyalarini rivojlantirish vazirligi

9-bob bo’yicha nazorat savollari

1. 
   Dasturiy ta’minotni modellashtirish deganda nimani tushunasiz?
   
2. 
   Matematik ta’minotning universalligi deyilganda nimani tushunasiz?
   
3. 
   Eksperimental metodlar deganda nimani tushunasiz?
   
4. 
   Dasturiy ta’minot matematik modellarini hosil qilishdagi umumiy metodika qanday jarayonlardan iborat?
   
5. 
   Dasturiy ta’minotni modellashtirish vazifalari nimalardan iborat.
   
6. 
   Yagona modellashtirish tili (UML) haqida nimalar bilasiz.
   
7. 
   UML diagrammalari haqida nimalar bilasiz.
   
8. 
   UMLda necha turdagi ob’ektlar mavjud.
   
9. 
   UMLdagi munosabatlarni aytib bering.
   
10. 
    UML diagrammalari uchun necha turdagi vizual belgilar mavjud.
    

9. BOB. DASTURIY TA’MINOTNING ARXITEKTURASI

§ 10.1. Dasturiy ta’minot arxitekturasi tushunchasi

Dasturiy ta’minot arxitekturasi (англ. software architecture) dasturiy ta’minot tizimini tashkil etish bo’yicha muhim qarorlar to’plamidir. Arxitektura quyidagilarni o’z ichiga oladi:

• 
  tizim yordamida tuziladigan strukturaviy elementlar va ularning interfeyslarini tanlash, shuningdek, strukturaviy elementlarning hamkorligi doirasidagi xatti-harakatlari;
  
• 
  tuzilma va xatti-harakatlarning tanlangan elementlarini tobora kattaroq tizimlarga ulash;
  
• 
  butun tashkilotni boshqaradigan arxitektura uslubi - barcha elementlar, ularning interfeyslari, hamkorligi va aloqasi
  

Dasturiy ta’minot arxitekturasini (SW) hujjatlashtirish ishlab chiquvchilar o’rtasidagi aloqa jarayonini soddalashtiradi, qabul qilingan loyiha qarorlarini qayd etish va tizimni ishlatuvchi xodimlariga ular haqida ma’lumot berish, komponentlar va loyiha shablonlarini boshqalarda qayta ishlatish imkonini beradi. “Dasturiy taʼminot arxitekturasi”ning umumiy qabul qilingan taʼrifi yoʻq. Shunday qilib, Software Engineering Institute veb-saytida ushbu kontseptsiyaning 150 dan ortiq ta’riflari berilgan.
Komyuter ilmlari sohasi yaratilganidan beri dasturiy tizimlarning murakkabligi bilan bog’liq muammolarga duch keldi. Ilgari murakkablik muammolari ishlab chiquvchilar tomonidan ma’lumotlar tuzilmalarini to’g’ri tanlash, algoritmlarni ishlab chiqish va vakolatlarni ajratish kontseptsiyasini qo’llash orqali hal qilingan. "Dasturiy ta’minot arxitekturasi" atamasi dasturiy ta’minotni ishlab chiqish sanoati uchun nisbatan yangi bo’lsa-da, bu sohaning asosiy tamoyillari 1980-yillarning o’rtalaridan boshlab dasturiy ta’minotni ishlab chiqish pionerlari tomonidan qo’llanilgan. Tizimning dasturiy ta’minot arxitekturasini tushunish va tushuntirishga birinchi urinishlar noaniqliklarga to’la edi va tashkilotchilikning yetishmasligidan aziyat chekdi, ko’pincha chiziqlar bilan
bog’langan blok sxemalarning diagrammasi sifatida ifodalangan. 1990-yillarda ushbu fanning asosiy jihatlarini aniqlash va tizimlashtirishga harakat qilindi. Bu vaqt ichida loyihalash shablonlari to’plami, loyihalash uslublari, eng yaxshi amaliyotlar, tavsiflash tillari va rasmiy mantiqning dastlabki to’plami ishlab chiqilgan.
Dasturiy ta’minot arxitekturasi sohasining asosiy g’oyasi - bu mavhumlik va vakolatlarni ajratish orqali tizimning murakkabligini kamaytirish g’oyasi. Bugungi kunga qadar "dasturiy ta’minot arxitekturasi" atamasining aniq ta’rifi bo’yicha kelishuv mavjud emas. Tizimni ishlab chiqishning "to’g’ri" yo’li haqida aniq qoidalarga ega bo’lmagan hozir vaqtda dasturiy ta’minot arxitekturasi loyihalash rivojlanayotgan soha sifatida hali ham fan va san’at aralashmasidir. "San’at" jihati shundaki, har qanday tijorat tizimi dastur yoki topshiriqni nazarda tutadi.
Dasturiy ta’minot arxitekturasi foydalanuvchisi nuqtai nazaridan, dasturiy ta’minot arxitekturasi har bir foydalanuvchining ixtisosligi bilan bog’liq muammolarni ko’chirish va hal qilish yo’nalishini ta’minlaydi, masalan, manfaatdor tomon, dasturiy ta’minot ishlab chiquvchisi, dasturiy ta’minotni qo’llab-quvvatlash jamoasi, dasturiy ta’minotni ta’minlovchi, dasturiy ta’minotni joylashtirish bo’yicha mutaxassis, dasturiy ta’minotni testdan o’tkazuvchi mutaxasis, shuningdek, oxirgi foydalanuvchilar. Shu ma’noda, dasturiy ta’minot arxitekturasi aslida tizimga turli nuqtai nazarlarni birlashtiradi. Ushbu bir nechta turli nuqtai nazarlarni dasturiy ta’minot arxitekturasida birlashtirish mumkinligi dasturiy ta’minotni ishlab chiqish bosqichidan oldin ham dasturiy ta’minot arxitekturasini yaratish zarurati va maqsadga muvofiqligi foydasiga dalildir.
Dasturiy ta’minot arxitekturasi kontseptsiya sifatida 1968 yilda Edsger Deykstra va 1970-yillarning boshlarida Devid Parnassusning tadqiqot ishlaridan boshlangan. Bu olimlar dasturiy ta’minot tizimining tuzilishi muhimligini va to’g’ri tuzilmani yaratish muhimligini ta’kidladilar. Ushbu sohani o’rganish 1990- yillarning boshidan arxitektura uslublari (naqshlar), arxitektura tavsifi tillari, arxitektura hujjatlari va rasmiy usullar bo’yicha tadqiqot ishlari bilan mashhur bo’ldi. Dasturiy ta’minot arxitekturasining fan sifatida rivojlanishida ilmiy-tadqiqot muassasalari muhim rol o’ynaydi. Karnegi Mellon universitetidan Meri Shou va
Devid Garlan "Dasturiy ta’minot arxitekturasi: 1996 yilda yangi fan bo’yicha istiqbollar" nomli kitob yozdilar, unda ular komponentlar, bog’lovchilar, uslublar va boshqalar kabi dasturiy ta’minot arxitekturasi tushunchalarini ilgari surdilar. Kaliforniya universitetida Irvine dasturiy ta’minot tadqiqot instituti birinchi navbatda arxitektura uslublari, arxitektura tavsifi tillari va dinamik arxitekturalarni o’rgandilar.
Birinchi dasturiy ta’minot arxitektura standarti IEEE 1471: ANSI/IEEE 1471- 2000: Asosan dasturiy ta’minot tizimlarini tavsiflash bo’yicha ko’rsatmalar. U 2007 yilda ISO ISO/IEC 42010:2007 nomi bilan qabul qilingan. Arxitektura tavsifi tillari (ADLS) dasturiy ta’minot arxitekturasini tavsiflash uchun ishlatiladi. AADL (SAE standarti), Rayt (Karnegi Mellon universitetida ishlab chiqilgan), Acme (Karnegi Mellon universitetida ishlab chiqilgan), xADL (UCIda ishlab chiqilgan), Darvin (London Imperial kollejida ishlab chiqilgan), DAOP-ADL (Malaga universitetida ishlab chiqilgan) va ByADL (L’Aquila universiteti, Italiya) kabi turli tashkilotlar tomonidan bir nechta turli ADLS ishlab chiqilgan. Ushbu tillarning barchasi uchun umumiy elementlar komponent, bog’lovchi va konfiguratsiya tushunchalaridir. Bundan tashqari, ixtisoslashgan tillardan tashqari, arxitekturani tavsiflash uchun UML birlashtirilgan modellash tili ko’pincha ishlatiladi.
Dasturiy ta’minot arxitekturasi odatda bino qurilishidagi har xil turdagi chizmalarga o’xshash bir nechta ko’rinishlarni o’z ichiga oladi. ANSI/IEEE 1471- 2000 tomonidan belgilangan ontologiyada ko’rinishlar ma’lum bir manfaatdor tomonlar to’plami nuqtai nazaridan arxitekturani tavsiflash uchun misollardir. Arxitektura ko’rinishi 2 komponentdan iborat:

• 
  Elementlar
  
• 
  Elementlar orasidagi aloqalar
  

Arxitektura ko’rinishlarini 3 asosiy turga bo’lish mumkin:

1. 
   Modulli ko’rinishlar (inglizcha - module views) - tizimni turli xil dasturiy bloklar strukturasi sifatida ko’rsatish.
   
2. 
   Komponentlar-va-konnektorlar (inglizcha - component-and-connector views)
   

• 
  tizimni parallel ishlaydigan elementlarning (komponentlarning) tuzilishi va
  

ularning o’zaro ta’sirini (bo’lovchilar) ko’rsatish.

3. 
   Joylashtirish (inglizcha - allocation views) - tizim elementlarini tashqi muhitda joylashtirishni ko’rsatadi.
   

Modulli ko’rinishlarga misollar:

• 
  Dekompozitsiya (ing. decomposition view) – “submoduldir” munosabati kontekstidagi modullardan iborat.
  
• 
  Foydalanish (ing. uses view) – “foydalanish” munosabati kontekstidagi modullardan iborat (ya’ni bir modul boshqa modul xizmatlaridan foydalanadi)
  
• 
  Qatlamli ko’rinish (ing. layered view) - funksionallik bilan bog’liq modullar guruhlarga (darajalarga) birlashtirilgan tuzilmani ko’rsatadi.
  
• 
  Sinflar turi/umumlashmalar (ing. class/generalization view) – “merosdan olingan” va “nasol” munosabati orqali bog’langan sinflardan iborat.
  

Komponent va konnektor turlariga misollar:

• 
  Jarayon ko’rinishi (inglizcha - process view) - aloqa, sinxronizatsiya va/yoki istisno operatsiyalari bilan bog’langan jarayonlardan iborat;
  
• 
  Parallel ko’rinish (inglizcha - concurrency view) - komponentlar va konnektorlardan iborat bo’lib, ulagichlar "mantiqiy oqimlar";
  
• 
  Umumiy maʼlumotlar koʻrinishi (inglizcha - shared-data (repository) view)
  

• 
  doimiy maʼlumotlarni yaratuvchi, saqlaydigan va qabul qiluvchi komponentlar va ulagichlardan iborat;
  
  • 
    Mijoz-server ko’rinishi (inglizcha - client-server view)- o’zaro ta’sir qiluvchi mijozlar va serverlardan, shuningdek ular orasidagi konnektorlardan iborat (masalan, protokollar va umumiy xabarlar).
    

Joylashish turlariga misollar:

• 
  Deployment (ing. deployment view) - dasturiy ta’minot elementlari, ularni jismoniy muhitda joylashtirish va aloqa elementlaridan iborat.
  
• 
  Amalga oshirish (ing. implementation view) - dastur elementlari va ularning turli muhitdagi fayl tuzilmalariga mos kelishi (ishlab chiqish, integratsiya va boshqalar) dan iborat.
  
• 
  Ish topshirig’i ko’rinishi (ing. work assignment view)- modullardan va ularning har birini amalga oshirish uchun kim mas’ul ekanligi tavsifidan iborat.
  

Dasturiy ta’minot arxitekturasini tavsiflash uchun bir nechta tillar ishlab chiqilgan bo’lsa-da, hozircha qaysi qarashlar to’plamini ma’lumotnoma sifatida qabul qilish kerakligi haqida kelishuv mavjud emas. UML tili "dasturiy ta’minot tizimlarini (va nafaqat) modellashtirish uchun" standart sifatida yaratilgan. Loyihalashtirilgan tizimni turli sifat atributlari bilan qondirish uchun turli konstruktorlik shablonlari qo’llaniladi. Har bir shablonning o’z maqsadi va kamchiliklari bor. Arxitektura shablonlariga misollar:

• 
  Ko’p qatlamli shablon (Layered pattern). Tizim diagrammada bir-biridan yuqorida ko’rsatilgan darajalarga bo’linadi. Har bir daraja faqat uning ostidagi 1- darajani chaqirishi mumkin. Shunday qilib, har bir darajaning rivojlanishi nisbatan mustaqil ravishda amalga oshirilishi mumkin, bu tizimning rivojlanish darajasini oshiradi. Ushbu yondashuvning kamchiliklari tizimning murakkabligi va ish sur’atining pasayishi hisoblanadi.
  
• 
  Broker shabloni (Broker pattern). Tizimda ko’p sonli modullar mavjud bo’lganda, ularning bir-biri bilan bevosita o’zaro ta’siri juda murakkablashadi. Muammoni hal qilish uchun vositachi (masalan, ma’lumotlar shinasi) joriy qilinadi, u orqali modullar bir-biri bilan aloqa qiladi. Shunday qilib, tizim modullarining o’zaro ishlashi ortadi. Barcha kamchiliklar vositachining mavjudligidan kelib chiqadi: u ish faoliyatini pasaytiradi, unga kirish imkoni bo’lmasligi butun tizimga kirish imkoni bo’lmasligini keltirib chiqarishi mumkin, u tashqi hujumlar uchun qulay ob’ekt bo’lishi mumkin.
  
  • 
    “Model - ko’rinish - nazoratchi” shabloni (Model – View - Controller pattern). Interfeysga qo’yiladigan talablar tez-tez o’zgarganligi sababli, ma’lumotlar bilan to’g’ri munosabatda bo’lish (o’qish, saqlash) uchun uni tez-tez o’zgartirish zarurati tug’iladi. Buning uchun Model-View-Controller (MVC) shablonida interfeys ma’lumotlardan ajratiladi. Bu sizga interfeyslarni o’zgartirish, shuningdek, ularning turli versiyalarini yaratish imkonini beradi. MVC-da tizim quyidagilarga bo’linadi:
    

1. 
   Ma’lumotlarni saqlash modeli
   
2. 
   Ma’lumotlar qismini ko’rsatadigan va foydalanuvchi bilan o’zaro aloqada bo’lgan ko’rinish
   
3. 
   Ko’rinishlar va model o’rtasida vositachi bo’lgan nazoratchi
   

Biroq, MVC kontseptsiyasi ham o’zining kamchiliklariga ega. Xususan, o’zaro ta’sirning murakkabligi tufayli tizimning tezligi pasayadi.

• 
  Mijoz-server shablon (Client-Server pattern). Agar ko’p sonli iste’molchilar tomonidan cheklangan foydalanishni talab qiladigan cheklangan miqdordagi resurslar mavjud bo’lsa, u holda mijoz-server arxitekturasini amalga oshirish qulay. Ushbu yondashuv tizimning kengaytirilishi va kirish imkoniyati mavjudligini oshiradi. Ammo shu bilan birga, server tizimda to’siq bo’lib qolishi mumkin, agar u mavjud bo’lmasa, butun tizim ishlamay qoladi.