Ma’ruza mavzulari Dars soatlari hajmi

9-Ma’ruza
Mavzu: Dasturiy ta’minot arxitekturasi va arxitekturaviy loyihalash. Arxitekturaviy loyihalash qarorlari Arxitekturaviy usullar Arxitekturaviy patternlar Ilova arxitekturalari
REJA:

1. 
   Arxitekturaviy loyihalash qarorlari
   
2. 
   Arxitekturaviy usullar
   
3. 
   Arxitekturaviy patternlar
   
4. 
   Ilova arxitekturalari
   

Arxitekturaviy loyihalash qarorlari
Arxitekturaviy loyihalash - bu tizimning funktsional va funktsional bo'lmagan talablarini qondiradigan tizim tashkilotini loyihalashda yaratilgan ijodiy jarayon. Hech qanday formulali arxitektura loyihalash jarayoni mavjud emas. Bu ishlab chiqilayotgan tizim turiga, tizim arxitektorining tajribasi va tajribasiga va tizimga qo'yiladigan o'ziga xos talablarga bog'liq. Binobarin, arxitekturaviy loyihalashni harakatlar ketma-ketligi emas, balki qabul qilinadigan qarorlar seriyasi sifatida ko'rib chiqish yaxshiroqdir.
Arxitektura loyihalash jarayonida tizim arxitektorlari tizimga va uning rivojlanish jarayoniga chuqur ta'sir ko'rsatadigan bir qator strukturaviy qarorlar qabul qilishlari kerak ­. Ular o'zlarining bilim va tajribalariga asoslanib, 6.2-rasmda ko'rsatilgan asosiy savollarni ko'rib chiqishlari kerak.
Har bir dasturiy ta'minot tizimi noyob bo'lsa-da, bir xil dastur domenidagi tizimlar ko'pincha domenning asosiy tushunchalarini aks ettiruvchi o'xshash arxitekturaga ega. Misol uchun, amaliy mahsulotlar qatorlari - bu asosiy arxitektura atrofida qurilgan, mijozlarning muayyan talablarini qondiradigan variantlari bo'lgan ilovalar. Tizim arxitekturasini loyihalashda ­siz tizimingiz va kengroq dastur sinflari nimada umumiylik borligini va ushbu ilova arxitekturasidan qancha bilimlarni qayta ishlatishingiz mumkinligini hal qilishingiz kerak.
Tizimning funktsional bo'lmagan xususiyatlari va dasturiy ta'minot arxitekturasi o'rtasidagi yaqin bog'liqlik tufayli arxitektura uslubi va tuzilishini tanlash tizimning funktsional bo'lmagan talablariga bog'liq bo'lishi kerak:

1. 
   Ishlash Agar unumdorlik muhim talab bo'lsa, arxitektura muhim operatsiyalarni kichik sonli komponentlar ichida lokalizatsiya qilish uchun mo'ljallangan bo'lishi kerak, bu komponentlar tarmoq bo'ylab taqsimlangan emas, balki bir xil kompyuterda joylashtirilgan. Bu kichik, mayda komponentlar emas, balki bir nechta nisbatan katta komponentlardan foydalanishni anglatishi mumkin. Katta komponentlardan foydalanish komponentlar aloqalari sonini kamaytiradi, chunki tegishli tizim xususiyatlari o'rtasidagi o'zaro ta'sirlarning aksariyati komponent ichida sodir bo'ladi. Shuningdek, siz tizimni turli protsessorlarda takrorlash va exe ni kesish imkonini beruvchi ish vaqti tizimi tashkilotlarini ko'rib chiqishingiz mumkin .­
   
2. 
   Xavfsizlik Agar xavfsizlik muhim talab bo'lsa, arxitektura uchun qatlamli strukturadan ­foydalanish kerak, eng muhim aktivlar ichki qatlamlarda himoyalangan va bu qatlamlarga yuqori darajadagi xavfsizlik tekshiruvi qo'llaniladi.
   
3. 
   Xavfsizlik Agar xavfsizlik muhim talab bo'lsa, arxitektura xavfsizlik bilan bog'liq operatsiyalar bitta komponentda yoki oz sonli komponentlarda birgalikda joylashgan tarzda ishlab chiqilishi kerak. Bu xavfsizlikni tekshirish xarajatlari va muammolarini kamaytiradi va ishlamay qolganda tizimni xavfsiz o'chirib qo'yishi mumkin bo'lgan tegishli himoya tizimlarini taqdim etish imkonini beradi.
   

Mavjudlik Agar mavjudlik muhim talab bo'lsa, tizimni to'xtatmasdan komponentlarni almashtirish va yangilash mumkin bo'lishi uchun arxitektura keraksiz komponentlarni o'z ichiga oladigan tarzda ishlab chiqilishi kerak. Men 11-bobda yuqori mavjud tizimlar uchun nosozliklarga chidamli ­tizim arxitekturasini tasvirlayman.

1. 
   Texnik xizmat ko'rsatish Agar texnik xizmat ko'rsatish muhim talab bo'lsa, tizim arxitekturasi ­osongina o'zgartirilishi mumkin bo'lgan nozik, mustaqil tarkibiy qismlardan foydalangan holda ishlab chiqilishi kerak. Ma'lumot ishlab chiqaruvchilarni iste'molchilardan ajratish va umumiy ma'lumotlar tuzilmalaridan qochish kerak.
   

Shubhasiz, ushbu arxitekturalarning ba'zilari o'rtasida potentsial ziddiyat mavjud. Misol uchun, katta komponentlardan foydalanish unumdorlikni yaxshilaydi va kichik, nozik donli qismlardan foydalanish esa barqarorlikni yaxshilaydi. Agar unumdorlik va xizmat ko'rsatish muhim tizim talablari bo'lsa, unda ba'zi murosaga kelish kerak. Siz buni ba'zan tizimning alohida qismlari uchun turli Arxitektura patternlari yoki uslublaridan foydalanib qilishingiz mumkin. Xavfsizlik endi deyarli har doim muhim talab bo'lib, siz xavfsizlikni ta'minlaydigan va boshqa funktsional bo'lmagan talablarni qondiradigan arxitekturani loyihalashingiz kerak.

1. 
   Tizim arxitekturasini loyihalash va hujjatlashtirishda qanday qarashlar yoki istiqbollar foydali ?­
   
2. 
   Arxitektura modellarini tavsiflash uchun qanday belgilar qo'llanilishi kerak?
   

Tizim arxitekturasi haqidagi barcha tegishli maʼlumotlarni bitta diagrammada tasvirlab boʻlmaydi, chunki grafik model tizimning faqat bitta koʻrinishini yoki istiqbolini koʻrsatishi mumkin. U tizimning modullarga qanday ajralishini, ish vaqti jarayonlarining o'zaro ta'sirini yoki tizim komponentlarining tarmoq bo'ylab taqsimlanishining turli usullarini ko'rsatishi mumkin. Bularning barchasi turli vaqtlarda foydali bo'lganligi sababli, dizayn va hujjatlar uchun odatda dasturiy ta'minot arxitekturasining bir nechta ko'rinishini taqdim etishingiz kerak.
Qanday qarashlar kerakligi haqida turli fikrlar mavjud. Krutchen (Krutchen 1995) dasturiy ta'minot arxitekturasining mashhur 4+1 ko'rinish modelida shunday bo'lishi kerakligini taklif qiladi.

umumiy foydalanish holatlari yoki stsenariylar orqali bog'lanishi mumkin bo'lgan to'rtta asosiy me'moriy ko'rinish bo'lishi mumkin ( 6.3-rasm). U quyidagi fikrlarni taklif qiladi:

1. 
   Tizimdagi asosiy abstraktsiyalarni ob'ektlar yoki ob'ektlar sinflari sifatida ko'rsatadigan mantiqiy ko'rinish . Ushbu mantiqiy ko'rinishda tizim talablarini ob'ektlar bilan bog'lash mumkin bo'lishi kerak.
   
2. 
   Ishlash vaqtida tizim o'zaro ta'sir qiluvchi jarayonlardan qanday tashkil topganligini ko'rsatadigan ­jarayon ko'rinishi . Ushbu ko'rinish unumdorlik va mavjudlik kabi funktsional bo'lmagan tizim xususiyatlari haqida xulosa chiqarish uchun foydalidir.
   
3. 
   Dasturiy ta'minot ishlab chiqish uchun qanday parchalanishini ko'rsatadigan ­ishlab chiqish ko'rinishi ; ya'ni, u dasturiy ta'minotning yagona ishlab chiquvchi yoki ishlab chiqish guruhi tomonidan amalga oshiriladigan komponentlarga bo'linishini ko'rsatadi. Ushbu ko'rinish dasturiy ta'minot menejerlari va dasturchilar uchun foydalidir.
   
4. 
   tizimdagi protsessorlar bo'ylab qanday taqsimlanganligini ko'rsatadigan jismoniy ­ko'rinish . Ushbu ko'rinish tizimni joylashtirishni rejalashtirayotgan tizim muhandislari uchun foydalidir.
   

Amalda, tizim arxitekturasining kontseptual qarashlari deyarli har doim ­loyihalash jarayonida ishlab chiqiladi . Ular manfaatdor tomonlarga tizim arxitekturasini tushuntirish va arxitektura qarorlarini qabul qilish haqida ma'lumot berish uchun ishlatiladi. Loyihalash jarayonida tizimning turli jihatlari muhokama qilinganda boshqa qarashlarning ba'zilari ham ishlab chiqilishi mumkin, ammo kamdan-kam hollarda barcha nuqtai nazardan to'liq tavsifni ishlab chiqish kerak. Keyingi bo'limda muhokama qilinadigan arxitektura patternlarini tizimning turli ko'rinishlari bilan bog'lash ham mumkin.
Men bu fikrga qo'shilmayman. UML ob'ektga yo'naltirilgan tizimlarni tavsiflash uchun mo'ljallangan va me'moriy dizayn bosqichida siz ko'pincha tizimlarni abstraktsiyaning yuqori darajasida tasvirlashni xohlaysiz. Ob'ekt sinflari arxitektura tavsifi uchun to'liq foydalanish uchun amalga oshirishga juda yaqin . ­Men UML ni loyihalash jarayonida foydali deb bilmayman va tezroq yoziladigan va doskada osongina chiziladigan norasmiy yozuvlarni afzal ko'raman. 5 -bobda muhokama qilinganidek, arxitekturani batafsil hujjatlashtirganda yoki modelga asoslangan ishlab chiqishdan foydalanganda UML eng qimmatlidir .
Agile usullaridan foydalanuvchilarning ta'kidlashicha, batafsil dizayn hujjatlari asosan foydalanilmaydi. Shunday qilib, ushbu hujjatlarni ishlab chiqish vaqt va pulni behuda sarflashdir. Men bu fikrga ko'p jihatdan qo'shilaman va o'ylaymanki, tanqidiy tizimlardan tashqari, Krutchenning to'rtta nuqtai nazaridan batafsil me'moriy tavsifni ishlab chiqishning hojati yo'q ­. Siz muloqot uchun foydali bo'lgan qarashlarni ishlab chiqishingiz kerak va sizning me'moriy hujjatlaringiz to'liq yoki to'liq emasligi haqida tashvishlanmaslik kerak.