1 Shablon nima?




Download 2.51 Mb.
Sana05.01.2024
Hajmi2.51 Mb.
#130898
Bog'liq
Loyihalash yakuniy javoblar 2
9fd832dc-e38c-46ad-88a5-ef68cbc9ac2f, Savollar va javobi, семинар сўзи Хилола, Tarixdan hikoyalar. 5-sinf (2015, U.Jo\'rayev, Q.Usmonov), Фанлар, Mustaqil ta'lim topshirig'i, 1. Mavzu. Rekursiv jarayonlarni tashkil etish-hozir.org (2), 4242-Rekursiv jarayonlarni tashkil etish-fayllar.org, 4242-Rekursiv jarayonlarni tashkil etish-fayllar.org (1), nutq,ko\'nikma va malakalarni nazorat qilish, python by akhilesh, 19- son Jurnal , 200, ONA TILI INGLIZ TILI — копия

(Yakuniy savollari 5 bo’limga bo’lingan. yakuniydagi 5 ta savol har bir bo’limdagi 1 ta savoldan iborat bo’lishi mumkun. Yani kamida eng oson 4 ta bo’limini yaxshi o’qisa o’tish mumkun.)

1) Shablon nima?


Shablon hayotning turli sohalarida, asosan tabiatda va dizaynda takrorlanadigan elementdir .
"Dizayn namunasi" atamasi arxitekturadan kelib chiqqan va arxitektor Kristofer Aleksandr tomonidan binolar va shaharlarni loyihalashda yuzaga keladigan muammolarni hal qilish uchun kiritilgan . Ammo uning so'zlari ≪ har qanday shablon bizning ishimizda qayta-qayta paydo bo'ladigan muammoni, shuningdek uni hal qilish tamoyilini tasvirlaydi va bu yechim hech narsani qayta kashf qilmasdan million marta ishlatilishi mumkin bo'lgan tarzda ≫ ham to'g'ri.
Dizayn shablonlari nima? Dizayn shablonlari ( Dizayn Shablonlar dasturiy ta'minotni ishlab chiqishda keng tarqalgan muammolarni hal qilish uchun nomlardir . Bunday holda, tez-tez uchraydigan umumiy rasmiylashtirilgan muammolar to'plami mavjud deb taxmin qilinadi va shablonlar ushbu muammolarni hal qilish uchun bir qator printsiplarni taqdim etadi.
Shablonlar - bu dasturchilarga har bir tizimni qurish uchun noldan boshlash o'rniga mavjud bilimlardan foydalanishga imkon beruvchi qurilish bloklari. Bundan tashqari, ular boshqa ishlab chiquvchilarga ularning loyihalari ushbu tizim bilan qanday o'zaro ta'sir qilishini tushunishga yordam beradigan standart modellar to'plamiga ega.
2) Arxitekturaviy shablon nima?
Dasturiy tizim arxitekturasi alohida arxitekturaviy shablonlar va stillarga asoslangan. Arxitekturaviy shablonlar xuddi klient-server tashkillanishi yoki bosqichlangan arxitektura kabi tizimni tashkillashtirish tushunchasidir. Arxitekturaviy shablonlar turli dasturiy tizimlarda qo’llanilgan arxitekturalar jamlanmasini o’z ichiga oladi. Tizim uchun arxitektura tanlashda ehtiyotkorlik bilan qaror qabul qilishingiz lozim.
3) Ko’p qatlamli arxitektura?
•Tizimni qismlarga ajratishning samarali usullaridan biri ko'p qatlamli tuzilmalardan foydalanishdir. Ushbu yondashuv bitta kompyuterda o'rnatilgan ilovalar uchun ham, tarqatilgan tizimlar uchun ham qo'llaniladi. Odatda qatlamlarga bo'linishlar (bunday variantlar uchun) ma'no jihatidan o'xshash, ammo ularni tavsiflash uchun ishlatiladigan terminologiyada farqlar mavjud.

4) Kanallar va filtrlar arxitekturasi?


5) Mijoz server arxitekturasi?
•Tarqalgan tizimlar uchun odatiy holat "mijoz-server" uslubidan foydalanish bo'lib, uni amalga oshirish uchun tizimning ma'lum bir funksiyaga ega bo'lgan qismi serverga, boshqa qismi esa foydalanuvchining mijoz saytlariga joylashtiriladi.
•Komponentlar: server quyi tizimi mijoz quyi tizimining bir nechta nusxalariga xizmat ko'rsatadi;
•Ulagichlar: tarmoq; mijoz odatda serverdan xizmatlar talab qiladi
•Afzalliklari: tarqatish, kengayish imkoniyati
•Kamchiliklari: sezgirlik (agar tarmoq sekin bo'lsa), mustahkamlik (agar server ishlamay qolsa)

6) Model View Controller arxitekturasi


•Komponentlar: model asosiy funksionallik va ma'lumotlarni o'z ichiga oladi, ko'rinishlar foydalanuvchiga ma'lumotlarni ko'rsatadi va kontrollerlar foydalanuvchi kiritishini boshqaradi.
•Ulagichlar: o'zgartirish-tarqatish mexanizmi (kuzatuvchi)
•Afzalliklari: interaktivlik, kengaytirilishi, model va taqdimotni ajratish
•Kamchiliklari: juda kichik o'lchamli (og'ir dizayn), murakkablashishi mumkin
7) Voqealarga asoslangan arxitektura
Hodisa uslubi tizim o'zaro aloqada bo'lgan tegishli turdagi hodisaga (muntazam yoki tasodifiy) kiradigan ilovalarni yaratish uchun ishlatiladi

8) Mikroservisga asoslangan arxitektura
Mikroservisga asoslangan dasturiy ta'minot arxitekturalari SOA modelining mohiyatan modernizatsiya qilingan ilovalari. Dasturiy ta'minot qurilish bloklari xizmatlar sifatida ishlab chiqilgan APIlar kerakli tarzda chaqirish mumkin. API vositachisi qurilish bloklariga kirishga vositachilik qiladi va hamma xavfsizlik va nazorat sozlamalariga rioya qilishini ta'minlaydi. Dasturiy texnikasi, shuningdek, mikro -xizmatlarning har xil kirish -chiqish formatlarini ulardan foydalanadigan ilovalarga moslashtirish uchun ham kiritilgan.
Mikroservislar arxitekturasining afzalliklari
Veb-platforma Microservices Architecture-dan foydalanishda odatda quyidagi afzalliklarga ega:
Hal qiling har bir muammo yoki muammoni muayyan vaziyatda ishtirok etgan har bir kichik mikroservisga murojaat qilish orqali osonlikcha taqdim etish.
Yengillashtirish uchun xizmatlarning umumiy yoki global ishlamay qolishi, chunki mikroservis ishlamay qolganda, bu boshqalarga ta'sir qilmaydi, chunki ular umuman mustaqil.
Yengillashtirish uchun to'liq yoki o'ziga xos funktsiyalarni yoki xizmatlarni ishga tushirish va birlashtirish, chunki har bir Microservice qo'shilishi yoki olib tashlanishi va alohida va bosqichma-bosqich yangilanishi mumkin.
Yaxshilash uchun barcha turdagi qurilmalar va platformalardan yaratilgan dasturlarga yoki xizmatlarga kirish.
Ortadi platformaning ko'p qirraliligi, chunki Microservices turli xil serverlarda tarqatilishi va turli tillarda yozilishi mumkin.

9) UML tili


UML (англ. Unified Modeling Language —birlashtirilgan modellashtirish tili) - bu dasturiy ta'minotni ishlab chiqish sohasidagi ob'ektlarni modellashtirish, biznes jarayonlarini modellashtirish, tizimni loyihalash va tashkiliy tuzilmalarni namoyish qilish uchun grafik tavsiflash tili. UML keng tarqalgan til; bu UML modeli deb nomlangan tizimning mavhum modelini yaratish uchun grafik yozuvlardan foydalanadigan ochiq standart. UML asosan dasturiy ta'minot tizimlarini aniqlash, tasavvur qilish, loyihalash va hujjatlashtirish uchun yaratilgan. UML dasturlash tili emas, lekin UML modellari asosida kod yaratish mumkin.
Yagona modellashtirish tili, shuningdek, nomi bilan ham tanilgan UML, standartlashtirilgan modellashtirish tilidir. U birlashtirilgan diagrammalar to'plamidan iborat. Bu tizim va dasturiy ta'minotni ishlab chiquvchilarga artefaktlarning dasturiy tizimlarini vizuallashtirish, qurish va hujjatlashtirishda yordam berishdir. Shuningdek, u biznesni modellashtirish va boshqa dasturiy ta'minot bo'lmagan tizimlarni o'z ichiga oladi. UML massiv, murakkab tizimlarni taqlid qiluvchi eng yaxshi muhandislik yondashuvlarini birlashtiradi. Ob'ektga yo'naltirilgan dasturiy ta'minotni yaratish va dasturiy ta'minotni ishlab chiqish jarayoni UMLga tayanadi. UML dasturiy ta'minot loyihasi dizaynini etkazish uchun grafik belgilardan foydalanadi. Jamoalar UML yordamida muloqot qilishlari, dizaynlarni o'rganishlari va dasturiy ta'minotning arxitektura dizaynini sinab ko'rishlari mumkin. UML tizimining yagona vizual tasviri UML diagrammasida ko'rsatilgan. Bu ishlab chiquvchilarga yoki biznes egalariga tizim tuzilishini tushunish, tekshirish va o'rnatishda yordam berishdir. UML diagrammasi biznes jarayonlarini modellashtirish uchun eng ko'p ishlatiladigan vositalardan biri sifatida paydo bo'ldi. Shunday qilib, ob'ektga yo'naltirilgan dasturiy ta'minotni yaratish uchun ham juda muhimdir.
UML diagrammasining ikkita asosiy turi mavjud Strukturaviy UML diagrammasi va Xulq-atvor UML diagrammasi. Har bir UML diagramma turi o'zining kichik turlariga ega. Ushbu qismda biz har bir diagrammaning asosiy maqsadlarini bilish uchun ularni batafsilroq muhokama qilamiz.
Strukturaviy diagrammalar
Ushbu diagrammalar bir nechta ob'ektlarni, shuningdek, tizimning statik tuzilishini ko'rsatadi. Bir yoki bir nechta mavhum amalga oshirish tushunchalari strukturaviy diagrammaning elementlari orasida bo'lishi mumkin.

10) Use Case diagrammalari


Tizimning funktsional talablari foydalanish holatlari modelida tasvirlangan. Bu tizimning muhiti va kutilayotgan funksionallikning simulyatsiyasi.

11) Faoliyat diagrammasi
Faoliyat diagrammasi turli xil faoliyat turlarining o'zaro bog'liqligini ko'rsatish uchun ishlatiladi. Shuningdek, u tizimdagi harakatlarni o'z ichiga oladi va foydalanish holatini bajarish bilan bog'liq qadamlarni ko'rsatadi.

12) O’zaro ta’sirning umumiy diagrammasi
O'zaro ta'sirning umumiy diagrammasi tizimning murakkab o'zaro ta'sirini oddiyroq shakllarga ajratadi. U bir qator tadbirlarni ko'rsatadi. Biroq, o'zaro ta'sirni ko'rib chiqish diagrammalarida Faoliyat diagrammalariga qaraganda ko'proq jihatlar mavjud. U o'zaro ta'sir, vaqt cheklovlari va boshqalarni o'z ichiga oladi.

13) Vaqt diagrammasi
Ob'ekt/larning xatti-harakati ma'lum vaqt oralig'ida vaqt diagrammasida tasvirlangan. Ketma-ketlik diagrammasining ma'lum bir turi vaqt diagrammasi hisoblanadi. Vaqt chapdan o'ngga ko'payishi uchun o'qlar aylantiriladi.

14) Aloqa diagrammasi
Ob'ektlar orasidagi ketma-ket aloqalarni ko'rsatishda aloqa diagrammasi qo'llaniladi. U asosiy e'tibor sifatida asosiy ob'ektlar va ularning munosabatlarini o'z ichiga oladi. Aloqa diagrammalarida xabarlar oqimini tasvirlash uchun naqshlar va ishora qiluvchi strelkalar ishlatiladi.\

15) Mashina diagrammasi
Bu UMLda tizimlarning harakatini tasvirlash uchun ishlatiladigan diagramma turi. U Devid Xarel tomonidan davlat diagrammalari kontseptsiyasiga asoslangan. Davlat diagrammalarida ruxsat etilgan holatlar va o'tishlar tasvirlangan. U ushbu o'tishlarga ta'sir qiluvchi voqealarni o'z ichiga oladi.

16) Ketma-ketlik diagrammasi
Ketma-ketlik diagrammasi vaqt ketma-ketligiga asoslangan ob'ektlarning hamkorligini modellashtiradi. Bu muayyan foydalanish stsenariysida narsalar bir-biri bilan qanday bog'liqligini ko'rsatadi.

17) Sinf diagrammasi
Bu eng tez-tez ishlatiladigan UML diagrammasi pastki toifasidir. Barcha ob'ektga yo'naltirilgan dasturiy ta'minot tizimlarining asosiy toshi sinf diagrammasi hisoblanadi. Tizimning sinflari va atributlariga qarab, foydalanuvchilar uning statik tuzilishini tasavvur qilishlari va uning sinflari bir-biri bilan qanday bog'liqligini aniqlashlari mumkin.

18) Obyekt diagrammasi



"Obyekt diagrammasi - bu ob'ektlar va ma'lumotlar qiymatlarini o'z ichiga olgan misollar grafigi. Statik obyekt diagrammasi sinf diagrammasining namunasidir; u bir vaqtning o'zida tizimning batafsil holatining suratini ko'rsatadi. Ob'ekt diagrammalaridan foydalanish ancha cheklangan, ya'ni ma'lumotlar strukturasi misollarini ko'rsatish uchun."
19) Komponent diagrammasi
UML-dagi komponentlar diagrammasi dasturiy ta'minot tizimlarini yaratish uchun qismlar qanday bog'langanligini ko'rsatadi. U dasturiy ta'minot komponentlari arxitekturasi o'rtasidagi bog'liqlikni ko'rsatadi.


Komponent diagrammasi 


Ushbu turdagi diagramma tizimning jismoniy dizaynida sinflar va ob'ektlarni komponentlar bo'yicha taqsimlash uchun mo'ljallangan. Ushbu turdagi diagrammalar ko'pincha birlik diagrammalari deb ataladi. Rasm - 4. Komponentlar diagrammasi Dasturiy ta'minot tizimining to'liq dizayni - bir-biriga mos kelishi kerak bo'lgan mantiqiy va fizik darajadagi modellar to'plami. UML tizimlarning modellarini jismoniy ko'rsatish uchun amalga oshirish diagrammalaridan foydalanadi, jumladan komponent diagrammasi va joylashtirish diagrammasi.Komponentlar diagrammasi, ilgari ko'rib chiqilgan diagrammalardan farqli o'laroq, tizimning fizik ko'rinishining xususiyatlarini tavsiflaydi. U dasturiy ta'minot komponentlari o'rtasida manba va bajariladigan kod bo'lishi mumkin bo'lgan bog'liqlikni o'rnatish orqali ishlab chiqilayotgan tizim arxitekturasini aniqlash imkonini beradi. Komponentlar diagrammasining asosiy grafik elementlari komponentlar, interfeyslar va ularning bog'liqligidir.Komponent diagrammasi quyidagi maqsadlar uchun ishlab chiqilgan: asturiy ta'minot tizimining dastlabki kodining umumiy tuzilishini vizuallashtirish;▪ dasturiy ta'minot tizimining bajariladigan versiyasining texnik xususiyatlari;dastur kodining alohida bo'laklaridan qayta foydalanishni ta'minlash; kontseptual va jismoniy ma'lumotlar bazasi sxemalarining ko'rinishlari. Komponentlar diagrammalarini ishlab chiqishda tizim tahlilchilari va arxitektorlari, shuningdek dasturchilar ishtirok etadilar. Komponentlar diagrammasi mantiqiy ko'rinishdan dastur kodi ko'rinishidagi loyihaning aniq amalga oshirilishiga izchil o'tishni ta'minlaydi. Ba'zi komponentlar faqat dastur kodini kompilyatsiya qilish bosqichida, boshqalari esa uni bajarish bosqichida mavjud bo'lishi mumkin. Komponentlar diagrammasi komponentlar orasidagi umumiy bog'liqlikni aks ettiradi, ikkinchisini tasniflagich sifatida ko'rib chiqadi. UML tilida jismoniy shaxslarni ifodalash uchun maxsus atama ishlatiladi - komponent... Komponent ma'lum bir interfeyslar to'plamini amalga oshiradi va modelning jismoniy ko'rinishi elementlarini umumiy belgilash uchun xizmat qiladi. Komponentni grafik tasvirlash uchun maxsus belgi qo'llaniladi - chap tomonda ikkita kichikroq to'rtburchaklar kiritilgan to'rtburchak. Katta to'rtburchak ichida komponent nomi va kerak bo'lganda qo'shimcha ma'lumotlar yoziladi. Ushbu belgining ko'rinishi komponent bilan bog'liq ma'lumotlarning tabiatiga qarab biroz farq qilishi mumkin



20) Kompozit tuzilma diagrammasi
Kompozit tuzilma diagrammalarida tizimning ichki tuzilishi, klassifikator xatti-harakatlari va sinf munosabatlari aks etadi

21) Joylashtirish diagrammasi
Diagramma ob'ektga yo'naltirilgan dasturiy ta'minot tizimining jismoniy tomonini modellashtirishga yordam beradi. Bu tizim arxitekturasini maqsadlarga dasturiy artefaktlarni joylashtirish sifatida ko'rsatadigan diagramma.

22) Paket diagrammasi
Paket diagrammasi UML strukturasidir. Bu paketlar va paketlar orasidagi bog'liqliklarni ko'rsatadigan diagramma. Model diagrammalarida tizimning turli ko'rinishlari ko'rsatilgan, masalan, ko'p qatlamli dastur - ko'p qatlamli dastur modeli.

23) Profil diagrammasi
Profil diagrammasi, Yagona Modellashtirish Tilidagi (UML) strukturaviy diagramma turi, muayyan domenlar va platformalar uchun UML modellarini sozlash uchun umumiy kengaytma mexanizmini taqdim etadi. Kengaytma mexanizmlari standart semantikani qat'iy qo'shimchalar bilan takomillashtirishga imkon beradi, bu ularning standart semantikaga zid bo'lishiga yo'l qo'ymaydi. Profillar sinflar, atributlar, operatsiyalar va harakatlar kabi muayyan model elementlariga qo'llaniladigan stereotiplar , tegli qiymat ta'riflari va cheklovlar yordamida aniqlanadi . Profil ma'lum bir domen (masalan, aerokosmik, sog'liqni saqlash, moliyaviy) yoki platforma (J2EE, .NET) uchun UMLni birgalikda moslashtiradigan bunday kengaytmalar to'plamidir.

24) Dasturiy ta’minot tizimlarini loyihalash faniga kirish
Tushuncha oling: Dasturiy ta'minot tizimlari haqida umumiy tushunchaga ega bo'lishingiz kerak. Bu, ma'lumotlar bazasi, maqsad va dasturlash tillari haqida tushuncha olishni o'z ichiga oladi.
Dasturlash tillari: Tanlangan dasturlash tilini o'rganing. Ko'p qo'llaniladigan tillar Python, Java, JavaScript, C++ kabi. O'z tili ni o'rganib, uni amaliyotda qo'llashga harakat qiling.
Loyihalashni o'rganing: Dasturiy ta'minot tizimlarini loyihalashda tajriba olish uchun loyihalashni o'rganing. Ushbu jarayonlar umumiyroq dasturlash metodologiyalari, interfeyslar va dizayn prinsiplari bo'yicha tushunchalarga ega bo'lishni o'z ichiga oladi.
Amaliyot: O'rganilgan bilimlaringizni amaliyotda qo'llang. Bunday dasturlar yozib, ularni test qilib ko'ring va yozgan dasturlaringizda qiyinchiliklar paydo bo'lsa, ularni bartaraf etishga harakat qiling.
Jamoa bilan ishlash: Dasturiy ta'minot tizimlarini loyihalashda jamoaviy ishlash muhimdir. Dasturlashda jamoa bilan ishlash, boshqa dasturchilar bilan tajribani almashingiz va muammolarni yechishingiz uchun yaxshi imkoniyat yaratadi.
Dasturiy ta'minot tizimini loyihalash samaradorligini quyidagi omillar guruhlari asosida baholash mumkin:
•Dasturiy ta'minot mahsuloti sifati
•Dasturiy ta'minot tizimini ishlab chiqish jarayonining samaradorligi
25) Arxitekturaviy dizayn
Dasturiy ta'minot tizimini loyihalashning ikki turi mavjud:
1. Arxitekturali dizayn - tizimning umumiy tuzilishini yaratish sifatida belgilanadi
2. Chuqurlashgan dizayn - modullar, operatsiyalar, munosabatlarning spetsifikatsiyasi va amalga oshirilishi sifatida aniqlanadi. Xuddi shu bosqichda tizimning tuzilishi yakuniga yetkaziladi.
26) Chuqurlashgan dizayn
Dasturiy ta'minot tizimini loyihalashning ikki turi mavjud:
1. Arxitekturali dizayn - tizimning umumiy tuzilishini yaratish sifatida belgilanadi
2. Chuqurlashgan dizayn - modullar, operatsiyalar, munosabatlarning spetsifikatsiyasi va amalga oshirilishi sifatida aniqlanadi. Xuddi shu bosqichda tizimning tuzilishi yakuniga yetkaziladi.
27) Dasturiy ta’minot nima?
•Dasturiy ta'minot - bu axborot tizimi uchun dasturlar, operatsion protseduralar va tegishli hujjatlar to'plami.
•Dasturiy ta'minot tizimlarini loyihalash - bu tabiiy va matematika fanlarining qo'llanilishi bo'lib, buning natijasida texnik vositalarning potentsial imkoniyatlari kompyuter dasturlari, tashkiliy protseduralar va tegishli hujjatlar orqali inson manfaatlari uchun amalga oshiriladi.
28) Chastotalar prinsipi
Dasturiy ta'minot tizimlarini ishlab chiqish tamoyillari
•Chastotalar printsipi. Algoritmlarda va qayta ishlangan tuzilmalarda harakatlar va ma'lumotlarni foydalanish chastotasiga qarab tanlashga asoslangan. Dasturiy ta'minot tizimining ishlashi paytida tez-tez sodir bo'ladigan harakatlar uchun ularni tezkor bajarish uchun sharoitlar taqdim etiladi.
29) Modullilik prinsipi
Dasturiy ta'minot tizimlarini ishlab chiqish tamoyillari
•Modullilik printsipi. Umuman olganda, modul deganda ko'rib chiqilayotgan tizimning funktsional elementi tushuniladi, u tizim talablari doirasida tugallangan va bajarilgan dizaynga ega va shu kabi elementlar yoki ma'lum bir yoki boshqa tizimning yuqori darajadagi elementlari bilan bog'lanish vositasi.
30) Funksional selektivlik prinsipi
•Funktsional selektivlik printsipi. Ushbu tamoyil chastota va modulli printsiplarning mantiqiy davomi bo'lib, hajmi mavjud ishlash hajmidan sezilarli darajada oshib ketadigan dasturiy ta'minot tizimlarini loyihalashda qo'llaniladi. Dasturiy ta'minot tizimida hisoblash jarayonini samarali tashkil etish uchun doimo tayyor bo'lishi kerak bo'lgan muhim modullarning bir qismi ajratilgan. Ushbu tamoyil ko'pincha dasturiy ta'minot tizimini bajariladigan modullarga bo'lish orqali amalga oshiriladi, ular o'rtasida ma'lumot almashiladi yoki dinamik ravishda yuklanadigan modullar tashkil etiladi
31) Ishlab chiqarish prinsipi
•Ishlab chiqarish printsipi. Ushbu printsipning asosiy pozitsiyasi dasturiy ta'minot tizimini dastlabki taqdim etish usulini belgilaydi, bu sizga texnik vositalarning ma'lum bir konfiguratsiyasiga, hal qilinadigan muammolar doirasiga, Foydalanuvchining ish sharoitlariga moslashtirishga imkon beradi.
32) Funksional ortiqchalik prinsipi
•Funktsional ortiqchalik printsipi. Ushbu printsip turli xil vositalar yordamida bir xil ishni bajarish imkoniyatini hisobga oladi. Ma'lumotlarni chiqarish uchun foydalanuvchi interfeysini ishlab chiqishda ushbu printsipni hisobga olish ayniqsa muhimdir
33) Standart prinsipi
•"Standart“ printsipi. U ishlab chiqarish bosqichida ham, tayyor dasturiy ta'minot bilan ishlashda ham tizim bilan aloqalarni tashkil qilishni osonlashtirish uchun ishlatiladi. Printsip tizimda dastur bilan ishlash shartlarini belgilaydigan tuzilmalar, modullar, konfiguratsiyalar va ma'lumotlarning ba'zi asosiy tavsiflarini saqlashga asoslangan.
34) Qo’shilish prinsipi
Butun tizim tamoyillari
•Qo'shilish printsipi dasturiy ta'minotni yaratish, ishlatish va ishlab chiqishga qo'yiladigan talablar uni o'z ichiga olgan murakkabroq tizim tomonidan belgilanadigan vaziyatni nazarda tutadi.
35) Tizim birligi prinsipi
Butun tizim tamoyillari
•Tizim birligi printsipi shundan iboratki, dasturiy ta'minotni yaratish, ishlatish va ishlab chiqishning barcha bosqichlarida uning yaxlitligi quyi tizimlar o'rtasidagi aloqalar, shuningdek, boshqaruv quyi tizimining ishlashi bilan ta'minlanadi.
36) Rivojlanish prinsipi
•Rivojlanish printsipi dasturiy ta'minot tizimidagi komponentlar va ular o'rtasidagi aloqalarni kengaytirish va takomillashtirish imkoniyatini nazarda tutadi. Ushbu tamoyil, shuningdek, ichki va tashqi o'zgarishlarga moslashish xususiyatlarini amalga oshirishni ta'minlaydi.
37) Murakkablik prinsipi
•Murakkablik printsipi shundan iboratki, dasturiy ta'minot qayta ishlashning barcha bosqichlarida alohida elementlar uchun ham, umuman ma'lumotlarning butun hajmi uchun ham ma'lumotlarni qayta ishlashning izchilligini ta'minlaydi.
38) Axborot birligi prinsipi
•Axborot birligi printsipi shundan iboratki, barcha quyi tizimlar, dasturiy vositalar va dasturiy ta'minot komponentlari umumiy atamalar, belgilar, konventsiyalar va taqdimot usullaridan foydalanadi.
39) Muvofiqlik prinsipi
•Muvofiqlik printsipi - axborot tizimining dasturiy ta'minot quyi tizimlarini qo'llab-quvvatlovchi tili, belgilari, kodlari va vositalari izchil bo'lishi, uning barcha quyi tizimlarining birgalikda ishlashini ta'minlash va butun tizim strukturasini ochiq saqlashdir.
40) O’zgarmaslik prinsipi
•O'zgarmaslik printsipi quyi tizimlar va dasturiy ta'minot komponentlari qayta ishlanayotgan axborotga o'zgarmasligini, ya'ni universal yoki tipik ekanligini oldindan belgilaydi.
41) Dizayn standarti
Standartlar turlari:
Dizayn standarti
- dizaynning har bir bosqichida zarur modellar (diagrammalar) to'plami va ularning tafsilotlari darajasi;
- diagrammalarda dizayn yechimlarini tuzatish qoidalari, shu jumladan ob'ektlarni nomlash qoidalari
- ishlab chiquvchilarning ish joylarini sozlash talablari
- loyiha ustida birgalikda ishlashni ta'minlash mexanizmi, shu jumladan loyihaning quyi tizimlarini birlashtirish qoidalari, loyihani barcha ishlab chiquvchilar uchun bir xil holatda saqlash qoidalari
42) "Dasturiy ta'minot arxitekturasi" ta'riflari
•Arxitektura - bu tizimning asosiy tashkil etuvchisi bo'lib, uning tarkibiy qismlari, ularning bir-biri bilan va atrof-muhit bilan munosabatlari, tizimni loyihalash va rivojlantirishni boshqaradigan tamoyillardir.
•Arxitektura - bu dasturiy ta'minot tizimini tashkil qilish, tizim yig'iladigan tizimli elementlar va ularning interfeyslari to'plami, ularning xatti-harakatlari bilan birgalikda ushbu elementlarning o'zaro ta'siri, elementlarni asta-sekin kattaroq quyi tizimlarga joylashtirish bo'yicha muhim qarorlar to'plami.
•Tashkilotni boshqaradigan arxitektura uslubi - elementlar va ularning interfeyslari, o'zaro ta'siri va tartibi.
•Dastur yoki kompyuter tizimining arxitekturasi - dastur elementlarini, bu elementlarning tashqi ko'rinadigan xususiyatlari va ular orasidagi munosabatlarni o'z ichiga olgan tizimning tuzilishi yoki tuzilmalari.
•Arxitektura - bu tashkilotning tuzilishi va tizim bilan bog'liq xatti-harakatlar. Arxitektura interfeyslar, qismlarni bog'laydigan ulanishlar va qismlarni yig'ish shartlari orqali o'zaro ta'sir qiluvchi qismlarga rekursiv parchalanishi mumkin. Interfeyslar orqali o'zaro ta'sir qiluvchi qismlarga sinflar, komponentlar va quyi tizimlar kiradi.
•Tizim yoki tizimlar to'plamining dasturiy ta'minot arxitekturasi dastur tuzilmalari va tizimlarni tashkil etuvchi tuzilmalar o'rtasidagi o'zaro aloqalar haqidagi barcha muhim dizayn qarorlaridan iborat. Dizayn qarorlari tizim muvaffaqiyatli bo'lishi uchun qo'llab-quvvatlashi kerak bo'lgan kerakli xususiyatlar to'plamini ta'minlaydi. Dizayn echimlari tizimni ishlab chiqish, qo'llab-quvvatlash va texnik xizmat ko'rsatish uchun kontseptual asosni ta'minlaydi.
43) Arxitekturaga ta'sir etuvchi omillar


Ishlab chiquvchi kompaniya arxitekturaga ta'sir qiladi
•Kompaniyalar turli aktivlarga, xususan, mavjud arxitektura va ularga asoslangan mahsulotlarga to'g'ridan-to'g'ri investitsiyalar kiritmoqda. Bu holda har bir keyingi loyiha bir qator shunga o'xshash tizimlarning davomi sifatida ishlab chiqilgan va uning smetasi mavjud mablag'lardan faol qayta foydalanishni o'z ichiga oladi.
•O'z strategik maqsadlaridan so'ng kompaniyalar ba'zan infratuzilmaga uzoq muddatli sarmoya kiritadilar; bunda taklif etilayotgan tizim ushbu infratuzilmani moliyalashtirish va kengaytirish vositalaridan biri sifatida tasavvur qilinadi.
•Ishlab chiquvchi kompaniyaning tashkiliy tuzilishi dasturiy ta'minot arxitekturasiga ma'lum miqdorda ta'sir ko'rsatadi.
Arxitekturaga arxitektorlarning tajribasi va odatlari ta'sir qiladi
•Ijobiy tajriba - uni keyingi ishlarda takrorlashdir.
•Salbiy tajriba - uni keyingi ishlarda ishlatishdan bosh tortishdir.
•Arxitektorlar yangi naqsh(pattern) va metodlar bilan tajriba qilishni yaxshi ko'radilar.
Arxitekturaga texnik baza ta'sir ko'rsatadi
Arxitektorning tayyorgarligi va tajribasi, xususan, texnik muhit bilan ishlashda namoyon bo'ladi(technical environment).
Texnik bazaga quyidagilar kiradi:
sanoat amaliyotlari
me'morni o'z ichiga olgan professional hamjamiyatda keng tarqalgan dasturiy ta'minot muhandisligi texnikasi.
44) Dasturiy ta'minot jarayoni va arxitektura-iqtisodiyot sikli
•Tizimning iqtisodiy modelini yaratish;
•Talablarni aniqlash;
•Yangi arxitektura yaratish yoki mavjud arxitekturani tanlash;
•Arxitektura haqidagi ma'lumotlarni hujjatlashtirish va tarqatish;
•Arxitektura tahlili yoki baholash;
•Arxitekturaga asoslangan tizimni amalga oshirish;
•Amalga oshirishning arxitekturaga muvofiqligini tekshirish;
45) Dasturiy ta'minot arxitekturasining qurilish bloklari
Dasturiy ta'minot arxitekturasining qurilish bloklari - komponent
Komponent - dasturiy ta'minot ko'rsatmalari va ichki holatlarning mavhum birligi bo'lib, uning interfeyslari orqali ma'lumotlarni o'zgartirishni ta'minlaydi.
Dasturiy ta'minot arxitekturasining qurilish bloklari - ma'lumotlar
Ma'lumotlar - bir komponentdan uzatiladigan yoki boshqa komponentdan konnektor orqali qabul qilingan axborot elementidir.
46) Repozitoriyga asoslangan uslub (Repository-based)
•Repositoryga asoslangan uslubda umumiy ma'lumotlar ma'lum ilovalar to'plami tomonidan almashiladi, ularning har biri ma'lumotlarga kirishda mustaqildir.

47) Hodisalarga asoslangan (Event-based) uslub
Hodisa uslubi tizim o'zaro aloqada bo'lgan tegishli turdagi hodisaga (muntazam yoki tasodifiy) kiradigan ilovalarni yaratish uchun ishlatiladi

48) Tengdoshlar (Peer-to-Peer) uslubi
•Peer-to-peer uslubi ishlab chiqilayotgan tizim ilovalardan (o'zaro ta'sir ishtirokchilari) iborat bo'lgan sharoitlarda qo'llaniladi, ularning har biri ma'lum miqdordagi boshqalar bilan bog'liq. Har bir o'zaro ta'sir aktida u faqat ikkita ishtirokchi o'rtasida o'rnatiladi va sodir bo'ladi.

49) Loyihalashga qanday yondashish kerak?
•Muammoni turli nuqtai nazardan o'rganing va tushuning
•Mumkin bo'lgan yechimlarni aniqlang va kelishuvlarni baholang
•Turli darajadagi tizimlarning turli modellarini ishlab chiqish abstraktsiya:
•1.global boshlash
•2.bo'linish (yuqoridan pastga)
•3.takrorlash(dizayn ko'pincha yuqoridan pastga va pastdan yuqoriga kombinatsiyadir)
Nima uchun aynan loyihalash
•Muloqotni osonlashtiradi
•Tizimni tushunishni osonlashtiradi
•Amalga oshirishni osonlashtiradi
•Muammolarni erta aniqlashga yordam beradi
•Mahsulot sifatini oshiradi
•Ta'mirlash xarajatlarini kamaytiradi
•Mahsulotni yangilashni osonlashtiradi
•“Dizaynni mustahkam, evristik jarayon sifatida ko'ring. Birinchi fikrlagan dizayningizga rozi bo'lmang. Hamkorlik qiling. Oddiylikka intiling. Sizga kerak bo'lganda prototipni ishlab chiqing. Takrorlang, takrorlang va yana takrorlang. Shundagina siz loyihangiz dizaynidan mamnun bo'lasiz.
50) Arxitektura uslublari va patternlari
•Arxitektura uslublari me'moriy dizayn qarorlarini cheklaydi va tizimga ega bo'ladigan sifatlarni belgilaydi.
•masalan, o'zgartirish mumkinmi? xavfsizmi? kengaytiriladiganmi? ishonchlimi? Va boshqalar.
•Arxitektura uslubi - umumiy me'moriy dizaynga berilgan nom. Arxitektura pattern- umumiy me'moriy patternni yechish usuli. (ba'zan bir-birining o'rnida ishlatiladi)Ikkalasi ham dasturiy ta'minot arxitekturasining umumiy tilini ta'minlaydi

51) SOLID prinsipi
SOLID dasturiy ta’minot tamoyillari; Bu Robert C. Martin tomonidan ilgari surilgan printsiplar to’plami bo’lib, ishlab chiqilgan dasturiy ta’minot moslashuvchan, qayta foydalanish mumkin, texnik xizmat ko’rsatish va tushunarli bo’lishini ta’minlaydi, kodlarning takrorlanishini oldini oladi. Maykl Feathers tomonidan belgilangan ushbu tamoyillarning maqsadi:
* Siz ishlab chiqayotgan dasturiy ta'minot kelajakdagi talablarga osongina moslashadi,
* Kodni o'zgartirmasdan yangi xususiyatlarni osongina qo'shishimiz mumkin bo'ladi.
* Yangi talablarga qaramay, kodda eng kam o'zgarishlarni ta'minlaydi,
* Shuningdek, doimiy tuzatish yoki hatto kodni qayta yozish kabi muammolar tufayli yuzaga keladigan vaqt yo'qotilishini minimallashtiradi.
OOP ning asosiy prinsiplari, SOLID tamoyillari va Design pattern turlari haqida o'zbek tilida qisqacha, aniq va sodda hayotiy misollar bilan keltirilgan kodlar jamlanmasi. Misollar va izohlar hali to'liq muakkammal holatda emas.
52) Single responsibility principle Yagona mas'uliyat tamoyili
/**
* Single-responsibility:
* SRP bu har bir classdan faqat yagon maqsadda foydalanishdir.
* Ya'ni bitta classga ko'plab turli xil vazifalarni yuklatish tizim arxitekturasini buzulishiga olib kelishi mumkun.
*/

// SRP ga to'g'ri kelmaydigan holat:


// Document nomli classdan hujjat haqidagi asosiy malumotlarni olish uchun va shu hujjatni turli formatlarga konvertatsiya qilish uchun foydalanilgan.
// Bitta classga turli xil vazifalarni yuklatish SRP prinsipini buzulishiga olib keladi.
class Document
{
protected $title;
protected $content;

public function __construct(string $title, string $content)


{
$this->title = $title;
$this->content= $content;
}

public function getTitle(): string


{
return $this->title;
}

public function getContent(): string


{
return $this->content;
}

public function convertToHtml() {


echo "DOCUMENT CONVERTED TO HTML";
}

public function convertToPdf() {


echo "DOCUMENT CONVERTED TO PDF";
}
}

// SRP ga to'g'ri keladigan holat:


// Bunda Document classi faqat hujjat haqida ma'lumot berish uchun xizmat qiladi.
// Convertatsiya va boshqa amallar uchun esa alohida interfeys va/yoki classlar yaratish to'g'ri yechim bo'ladi.
interface ConvertDocumentInterface
{
public function convert(Document $document);
}

class ConvertToHtml implements ConvertDocumentInterface


{
public function convert(Document $document)
{
echo "DOCUMENT CONVERTED TO HTML";
}
}

class ConvertToPdf implements ConvertDocumentInterface


{
public function convert(Document $document)
{
echo "DOCUMENT CONVERTED TO PDF";
}
}

class Document


{
protected $title;
protected $content;

public function __construct(string $title, string $content)


{
$this->title = $title;
$this->content= $content;
}

public function getTitle(): string


{
return $this->title;
}

public function getContent(): string


{
return $this->content;
}
}
53) Open/closed principle (OCP) Ochiq/yopiq tamoyili
/**
* Open-closed Principle:
* Tizim strukturasi uni kengaytirish uchun ochiq va qulay bo'lishi kerak ammo ichkariga o'zgartirish kiritish uchun
* yopiq bo'lishi kerak. Ya'ni tizimning kengaytirilishi quyi pog'onadagi classlar va ularning metodlarini ishlashiga
* hech qanday ta'sir qilmasligi kerak.
*/
// OCP ga to'g'ri kelmaydi:
// Ushbu misolda agar strukturaga to'rtburchakdan boshqa shakllar ham qo'ishladigan bo'lsa
// quyi Board classdagi yuzani hisoblash metodida ham o'zgarish qilishga to'g'ri keladi.
// Demak tizim kengayishi boshqa classlardagi metodlarga ta'sir qilgani sababli bu OCP prinsipiga zid bo'ladi.
class Rectangle
{
public $width;
public $height;

public function __construct(float $width, float $height)


{
$this->width = $width;
$this->height = $height;
}
}

class Board


{
public $rectangles = [];

// Tizimga har safar yangi shakl qo'shilganda bu metodni o'zgartirish kerak.


public function calculateArea()
{
$area = 0;
foreach ($this->rectangles as $rectangle) {
// Agar doska yuzi turli xil shakllardan iborat bo'lsa, ular uchun bu formula ishlamaydi.
$area += $rectangle->width * $rectangle->height;
}
return $area;
}
}

$rectangles = [


new Rectangle(2, 3),
new Rectangle(3, 4),
new Rectangle(4, 5),
];

// Faqat to'rtburchaklardan iborat doska yuzini hisoblash


$board = new Board();
$board->rectangles = $rectangles;
echo "AREA OF THE BOARD: " . $board->calculateArea();

// OCP ga to'g'ri keladi.


// 1. Barcha turdagi shakllar uchun umumiy interfeys yaratib olamiz
interface Shape
{
public function area();
}

// 2. Keyinchalik tizimga qo'shiladigan barcha shakllar shu interfeysdan meros oladi.


class Rectangle implements Shape
{
public $width;
public $height;

public function __construct(float $width, float $height)


{
$this->width = $width;
$this->height = $height;
}

// 3. Har bir shakl uchun maxsus yuzani hisoblash metodi va formulasi mavjud.


public function area()
{
return $this->width * $this->height;
}
}

// 4. Tizimga har safar yangi shakl qo'shish jarayoni xuddi shunday davom etaveradi.


// Yangi shakl qo'shilishi boshqa klasslarning ishlashiga umuman ta'sir qilmayapti.
class Circle implements Shape
{
public $radius;

public function __construct(float $radius)


{
$this->radius = $radius;
}

public function area()


{
return $this->radius * $this->radius * pi();
}
}

// Asosiy class esa o'zgartirishlar kiritish uchun yopiq holda qoladi.


class Board
{
public $shapes;

public function calculateArea()


{
$area = 0;
foreach ($this->shapes as $shape) {
$area += $shape->area();
}
return $area;
}
}

$shapes = [


new Circle(1),
new Circle(2),
new Circle(3),
new Rectangle(4, 5),
new Rectangle(5, 6),
new Rectangle(6, 7),
];

// Turli xil shakllardan iborat doska yuzasini hisoblash.


$board = new Board();
$board->shapes = $shapes;
echo "AREA OF THE BOARD: " . $board->calculateArea();

54) Liskov substitution principle (LSP) Liskov almashtirish tamoyili


/** Liskov substitution:
* Ota klass obyektini voris klass obyekti bilan hech qanday muammosiz almashtira olishimiz kerak.
* Ya'ni B class A classdan voris olsa, A class obyekti ishlatilgan joyda B klass obyektini ham ishlata olishimiz kerak.
* Agar voris klass obyekti ota klass obyektini o'rnini bosa olsa demak vorislik to'g'ri bajarilgan bo'ladi.
* Buning uchun voris classda override qilingan ota klass metodining qabul qiladigan argumentlari kamida ota classdagi bilan teng bo'lishi kerak.
* Xuddi shunday overrida bo'lgan metodning return tipi ham ota klassdagi metod bilan kamida bir xil bo'lishi talab qilinadi.
*/

interface UserInterface{


public function makeAction($action);
}

class User implements UserInterface {


public function makeAction($action): string
{
switch ($action) {
case 'VIEW':
return $this->view();
case 'UPDATE':
return $this->update();
default:
throw new ActionException('Action not allowed');
}
}

public function view(){


return 'view page';
}

public function update(){


return 'update page';
}
}

class Admin extends User {

// Liskov prinsipiga ko'ra voris class da override qilingan metodlarning argumentlari
// ota klassdagi metod bilan kamida teng bo'lishi shart.
// Override qilingan metodning qaytaradigan return tipi ham kamida ota klassdagi metod bilan bir xil bo'lishi shart.
public function makeAction($action): string
{
switch ($action) {
case 'VIEW':
return $this->view();
case 'UPDATE':
return $this->update();
case 'DELETE':
return $this->delete();
default:
throw new ActionException('Action not allowed');
}
}

public function delete(){


return 'delete page';
}
}

function getUser($role) {


switch ($role) {
case 'USER':
return new User();
case 'ADMIN':
default:
return new Admin();
}
}

// Admin class obyektini qaytadi. Admin class bu User classning vorisi hisoblanadi.


$user = getUser('ADMIN');

// Voris class obyekti orqali ota classdagi view() metodga murojat qildik.


// Demak ota klass obyekti o'rniga voris klass obyektidan muammosiz foydalana oldik.
$user->makeAction('VIEW');

55) Interface segregation principle (ISP) Interfeysni ajratish tamoyili


/**
* Interface Segregation:
* Foydalanuvchilarni hech qachon ularga keraksiz interfeysdan foydalanishga majbur qilmaslik kerak.
* Ya'ni foydalanuvchi biror interfeysni implement qilganida undagi keraksiz metodlarni ham elon qilishga majbur bo'lmasin.
* Bitta katta umumiy interfeysdan ko'ra alohida-alohida bir nechta maxsus interfeyslardan foydalanish samaraliroqdir.
*/

// Interface Segregation prinsipiga zid holat.


// Barcha turdagi transport uchun yagona interfeysdan foydalanilmoqda.
interface VehicleInterface
{
public function drive();
public function fly();
}

// FutureCar uchun drive() va fly() metodlaridan foydalanamiz.


class FutureCar implements VehicleInterface
{
public function drive()
{
echo 'Driving a future car!';
}

public function fly()


{
echo 'Flying a future car!';
}
}

// Ammo oddiy Car uchun fly() metodidan foydalanmaymiz.


class Car implements VehicleInterface
{
public function drive()
{
echo 'Driving a car!';
}

// Umumiy interfeys bu keraksiz metodni elon qilishga majbur qiladi.


public function fly()
{
throw new Exception('Not implemented method');
}
}

// Airplane uchun esa drive() metodi aslida kerak emas.


class Airplane implements VehicleInterface
{
public function drive()
{
throw new Exception('Not implemented method');
}

public function fly()


{
echo 'Flying an airplane!';
}
}

// Interface Segregation prinsipini to'g'ri qo'llash.


// Har bir transport turi uchun alohida interfeyslar yaratilgan.
// Yani mashina va samaliyot uchun alohida interfeys yaratilgan.
interface CarInterface {
public function drive();
}

interface AirplaneInterface {


public function fly();
}

// FutureCar classiga ikkala metod ham kerak.


class FutureCar implements CarInterface, AirplaneInterface {

public function drive() {


echo 'Driving a future car!';
}

public function fly() {


echo 'Flying a future car!';
}
}

// Car classiga faqat drive() metodi yetarli.


class Car implements CarInterface {

public function drive() {


echo 'Driving a car!';
}
}

// Airplane uchun esa fly() metodi kerak xolos.


class Airplane implements AirplaneInterface {

public function fly() {


echo 'Flying an airplane!';
}
}

56) Dependency inversion principle (DIP)Bog'liqlik inversiyasi tamoyili Dasturiy ta’minotni baholash nima?


/**
* Dependency Inversion:
* Yuqori darajadagi modullar quyi darajadagi modullarga bog'liq bo'lmasligi kerak.
* Ikkala turdagi modullar ham abstraktsiyalarga(interfeyslarga) bog'liq bo'lishi kerak.
* Ya'ni klasslarda metod argumenti yoki xususiyati sifatida obyektlardan emas interfeyslardan foydalanish to'g'ri bo'ladi.
* Prinsip yana ham tushunarli bo'lishi uchun quyidagi ma'lumotlar bazasi va UserDB klass misolini ko'rib chiqamiz.
*/

// Dependency Inversion ga zid bo'lgan holat:


// Bu yerda UserDB yuqori modul, MySQLConnection esa quyi modul hisoblanadi.
class MySQLConnection
{
public function connect() {
// Return the MySQL connection...
}
}

class UserDB


{
private MySQLConnection $dbConnection;

// Agar qachondir tizim MySQL dan PostgreSQL ga o'tkazilsa


// UserDB klassni qayta yozib chiqishga to'g'ri keladi (Bu esa OCP prinsipiga ham zid).
// Chunki bu tizim abstraksiyaga emas aynan bitta klass obyektiga qaram bo'lib qolgan.
public function __construct(MySQLConnection $dbConnection)
{
$this->$dbConnection = $dbConnection;
}

public function store(User $user)


{
// Store the user into a database...
}
}

// Dependency Inversion prinsipi asosida yozilgan to'g'ri yechim:


// Yuqori va quyi modullar abstraksiyaga bo'g'liq bo'lishi uchun avval shu asbtraksiyani yaratib olamiz.
interface DBConnectionInterface {
public function connect();
}

// Istalgan vaqtda istalgan ma'lumotlar bazasi uchun yangi klass yozishimiz mumkun.


// Lekin ushbu quyi klasslar ham asbtraksiyaga bog'liq bo'lishi kerak.
class MySQLConnection implements DBConnectionInterface {
public function connect() {
// Return the MySQL connection...
}
}

class UserDB {

private $dbConnection;

// 1. Bu yerda quyi klasslar yuqori(UserDB) klassga umuman bog'liq emas.


// 2. Ammo ikkala klass ham bitta abstraksiya(interfeys) ga bog'liq.
// Sodda qilib aytganda argument sifatida biror bir klass obyektidan emas uning interfeysida foydalandik.
// Demak tizim Dependency inversion prinsipi talabiga to'liq javob beradi.
public function __construct(DBConnectionInterface $dbConnection) {
$this->dbConnection = $dbConnection;
}

public function store(User $user) {


// Store the user into a database...
}
}
57) Dasturiy ta’minotni baholash nima uchun muhim?
•Dasturiy ta'minotni baholash o'z ehtiyojlarini qondiradigan dasturiy ta'minot sotib olishni istagan korxona va tashkilotlar uchun muhimdir va ularga sarmoyalariga yaxshi daromad keltiradi.
Dasturiy ta'minotni baholash o'z ehtiyojlarini qondiradigan dasturiy ta'minot sotib olishni istagan korxona va tashkilotlar uchun muhimdir va ularga sarmoyalariga yaxshi daromad keltiradi
•Dasturiy ta'minot dizayni bilan tanishib, funktsional imkoniyatlar va ishlash uchun dasturiy ta'minotni sinab ko'rish va dasturiy ta'minot hujjatlarini baholash, dasturiy ta'minotni baholash jarayonining bir qismidir. Dasturiy ta'minotni ishlab chiquvchilar, sinovchilar yoki tashqi baholovchilar baholashni amalga oshirishi mumkin. Dasturiy ta'minotni baholash ko‘p vaqt talab qiladigan jarayon. Ko'p hollarda sotuvchilar bilan gaplashish va har bir variantni ko’rib chiqish juda ko’p vaqt talab etadi.
Dasturiy ta'minotni baholash dasturiy ta'minotni yoki tizimning sifatini, qulayligi va samaradorligini aniqlaydi. Bu dasturiy ta'minotni ishlab chiqish jarayonida muhim qadamdir, chunki dasturiy ta'minot kerakli standartlar va texnik xususiyatlarga javob berishini va maqsadga muvofiqligini belgilaydi. 
Dasturiy ta'minotni baholash dasturiy ta'minotni ishlab chiqish jarayonida muhim bosqichdir, chunki u dasturiy ta'minotning talab qilinadigan standartlar va texnik shartlarga mos kelishini va uning mo'ljallangan maqsadiga mos kelishini aniqlaydi. Keling, uning muhim ahamiyatini bilib olaylik
58) Sifatni tekshirish
Sifatni ta'minlash uchun muhim ahamiyatga ega. Dasturiy ta'minotni baholash orqali yuzaga kelishi mumkin bo'lgan muammolarni ishlab chiqish jarayonining boshida topish va tuzatish mumkin. Bu dasturiy ta'minotdagi nuqsonlar, xatolar va xatolar sonini kamaytirishga yordam beradi. Bu uzoq muddatda vaqt va pulni tejash va dasturiy ta'minotning umumiy sifatini yaxshilash imkonini beradi
59) Foydalanuvchi qoniqishi
•Dasturiy ta'minotni baholash foydalanuvchi qoniqishi uchun juda muhimdir. Dasturiy ta'minotni foydalanuvchi nuqtai nazaridan baholash orqali uning mo'ljallangan foydalanuvchilari ehtiyojlariga javob berishini aniqlash mumkin. Bu foydalanuvchi qoniqishini oshirishga va foydalanuvchining dasturiy ta'minotdan noroziligini kamaytirishga yordam beradi.
60) Iqtisodiy samaradorlik

61) Doimiy takomillashtirish
•Dasturiy ta'minotni baholash kelajakdagi dasturiy ta'minot nashrlari uchun foydali fikr-mulohazalarni berishi mumkin. Bu dasturiy ta'minotning dolzarb bo'lib qolishiga, foydalanuvchilarning o'zgaruvchan ehtiyojlariga javob berishiga va bozorda raqobatbardosh bo'lib qolishiga yordam beradi.
62) Dasturiy ta'minotni baholashda kim ishtirok etishi kerak?
•Dasturiy ta'minotni baholash jarayoni murakkab va ko'plab odamlarni o'z ichiga oladi, masalan:
•Manfaatdor tomonlar, shu jumladan qaror qabul qiluvchi:
•Bu shaxslar baholashni to'g'ri yo'lga qo'yishda hal qiluvchi ahamiyatga ega bo'ladi.
•Mahsulotdan foydalanadigan odamlar
•Ushbu shaxslar dasturiy ta'minotning kundalik foydalanish uchun amaliy ekanligi haqida fikr bildirishlari mumkin. Dasturiy ta'minot murakkab yoki foydalanish qiyin bo'lsa, qabul qilish qiyinroq bo'ladi.
•IT va xavfsizlik jamoasi 
•Bu odamlar dasturiy ta'minotning texnik jihatdan qanday ishlashini aniqlashlari mumkin. Baholash jarayonining bir qismi bo'lganlar dasturiy ta'minotning mumkin yoki foydali ekanligini aniqlash uchun birgalikda ishlashlari kerak. Baholash guruhi qanchalik katta bo'lishi ko'p jihatdan tashkilot hajmiga va qanday dasturiy ta'minot baholanishiga bog'liq bo'ladi. Baholash jarayoni jamoaning asosiy yo'nalishi bo'lishi kerak. Baholash jamoa tuzilganidan keyin boshlanishi mumkin.
63) Dasturiy ta'minotni baholash mezonlari
•Ko'rib chiqish jarayonida foydalanish uchun mezonlar ro'yxatiga ega bo'lish juda muhimdir. Dasturiy ta'minot yoki dasturiy ta'minot kompaniya uchun yaxshi ishlaydimi yoki yo'qligini hal qilishda bir nechta narsalar haqida o'ylash kerak:
64) Baholashda Funksionallik
•Dasturiy ta'minotning funksionalligi e'tiborga olinadigan birinchi va eng muhim narsalardan biridir. Maqsad, dasturiy ta'minotning xususiyatlari va funktsiyalari ishlarni osonlashtirish yoki xatolarni bartaraf etish kabi asosiy muammolarni hal qila oladimi yoki yo'qligini aniqlashdir. Dasturiy ta'minot qanday ishlashini aniqlash uzoq vaqt talab qilishi mumkin, ammo bu eng muhim qadamlardan biridir.
65) UI va UX
Dasturiy ta'minotning foydalanuvchi interfeysi (UI) va foydalanuvchi tajribasi (UX) baholanishi kerak. Foydalanuvchilarning texnologiyani qanchalik yaxshi bilishi va ular dasturiy ta'minotni osongina o'zlashtira oladimi yoki yo'qligini o'ylab ko'rish talab qilinadi. Foydalanuvchilarni murakkab va qiyin dasturiy ta'minotni qabul qilish va ulardan foydalanishga undash qiyin bo'ladi. Yakuniy foydalanuvchining fikr-mulohazalari baholash jarayonining ushbu bosqichida bebaho bo'ladi
66) Ishbilarmonlik holati
•Yangi dasturiy ta'minotni faqat haqiqiy muammoni hal qilishga yordam bergan taqdirda sotib olish kerak. Natijada, baholash jarayoni biznesni o'z ichiga olishi kerak.
67) Narxlash
•Narx hal qiluvchi omil bo'lmasa-da, dasturiy ta'minotning hayotiyligini aniqlashda muhim rol o'ynaydi.
68) Qanday qilib dasturiy ta'minotni samarali baholash mumkin?
•Dasturiy ta'minotni baholash - bu dasturiy ta'minotning sifati va ma'lum bir maqsadga muvofiqligini aniqlash uchun tizimli yondashuv. Dasturiy ta'minotni baholashni o'tkazish uchun quyidagi bosqichlar mavjud:
69) Baholashning maqsadi va hajmini aniqlash
•Baholashni boshlashdan oldin uning maqsadi va hajmini aniqlash juda muhimdir. Bu baholash mezonlarini, dasturiy ta'minotning mo'ljallangan foydalanuvchilarini va baholashning kutilayotgan natijalarini aniqlashni o'z ichiga olishi mumkin.
70) Dasturiy ta'minot haqida ma'lumot to'plash
•Baholanayotgan dasturiy ta'minot haqida uning dizayni, foydalanuvchi qo'llanmalari, tizim talablari va har qanday ma'lum xato yoki muammolar kabi asosiy faktlarni to'plash
71) Baholashni rejalashtirish va amalga oshirish
•Baholash guruhi belgilangan maqsad va miqyosdan kelib chiqib baholashni rejalashtirishi va amalga oshirishi kerak. Dasturiy ta'minotni funksionalligi, unumdorligi va qulayligi uchun sinovdan o'tkazish va dasturiy ta'minot hujjatlarini ko'rib chiqish talab qilinishi mumkin.
72) Baholashda Natijalarni tahlil qilish

73) Baholash hisobotini tayyorlash
•Baholashdan olgan bilimlarni umumlashtiruvchi hisobot tuzish. Hisobotda baholash mezonlari, baholash jarayonining qisqacha tavsifi, baholash natijalari va ishlarni yaxshilash bo'yicha takliflar bo'lishi kerak

74) Natijalarni e'lon qilish


•. Baholash natijalari dasturiy ta'minotni ishlab chiquvchilar, sinovchilar, boshqaruv va oxirgi foydalanuvchilar kabi to'g'ri odamlar bilan bo'lishish kerak.
•Natija quyidagilarni o'z ichiga olishi kerak:
•To’plangan narsalarning qisqacha mazmuni.
•Qanday qilib narsalarni yaxshilash bo'yicha tavsiyalar.
•Qabul qilinishi kerak bo'lgan har qanday harakatlar.
75) Kuzatuv va doimiy takomillashtirish
•Baholashdan so'ng, tavsiya etilgan o'zgarishlar kiritilganligiga ishonch hosil qilish va dasturiy ta'minot qanchalik yaxshi ishlashini tekshirish uchun keyingi harakatlar bo'lishi kerak. Doimiy takomillashtirish bo'yicha tadbirlar, shuningdek, dasturiy ta'minotning dolzarb bo'lib turishi va foydalanuvchilarning o'zgaruvchan ehtiyojlari va umidlariga javob berishini ta'minlash uchun amalga oshirilishi kerak.
•Korxonalar ushbu jarayonda keltirilgan maslahatlarga amal qilish orqali dasturiy ta'minotni samarali baholashlari mumkin, ular o'z ehtiyojlarini qondiradigan va pul qiymatini ta'minlaydigan dasturiy ta'minotga sarmoya kiritishlarini ta’minlashlari mumkin.
76) Xulq atvorli shablonlar Mas'uliyat zanjiri
•Mas'uliyat zanjiri - bu so'rovlarni ishlovchilar zanjiri orqali ketma-ket o'tkazish imkonini beruvchi xatti-harakatlar dizayni. Har bir keyingi ishlov beruvchi so'rovni o'zi qayta ishlay oladimi yoki yo'qmi va so'rovni zanjir bo'ylab o'tkazishga arziydimi yoki yo'qligini hal qiladi.
77) BUYRUQ PATTERNI
•Buyruq - bu so'rovlarni ob'ektlarga aylantiradigan, usullarni chaqirishda, so'rovlarni navbatga qo'yishda, ularni jurnalga yozishda va operatsiyalarni bekor qilishni qo'llab-quvvatlashda ularni argument sifatida o'tkazishga imkon beruvchi xatti-harakatlar dizayni.

Download 2.51 Mb.




Download 2.51 Mb.