Ma’ruza mavzulari Dars soatlari hajmi

7.5 - rasm Ma'lumotlarni yig'ish tizimining arxitekturasi
7.4 -rasmda Aloqa havolasi sifatida ko'rsatilgan umumiy infratuzilmada xabarlarni translyatsiya qilish orqali . Har bir quyi tizim ushbu infratuzilmadagi xabarlarni tinglaydi va ular uchun mo'ljallangan xabarlarni oladi. Ushbu "tinglovchi modeli" ­taqsimlangan tizimlar uchun keng tarqalgan ishlatiladigan me'moriy uslubdir.
o'chirish kabi boshqaruv buyrug'ini olganida, ­buyruq boshqa quyi tizimlarning har biri tomonidan qabul qilinadi va keyin o'zini to'g'ri yo'l bilan o'chiradi. Ushbu arxitekturaning asosiy afzalligi shundaki, u quyi tizimlarning turli konfiguratsiyasini qo'llab-quvvatlash oson, chunki xabar yuboruvchisi ­xabarni ma'lum bir quyi tizimga yuborishi shart emas.
7.5 - rasmda 7.4 -rasmga kiritilgan ma'lumotlarni yig'ish quyi tizimining arxitekturasi ko'rsatilgan . Transmitter va Receiver ob'ektlari aloqalarni boshqarish bilan bog'liq va WeatherData ob'ekti asboblardan ­to'plangan va ob-havo ma'lumot tizimiga uzatiladigan ma'lumotlarni qamrab oladi. Ushbu tartibga solish 21-bobda muhokama qilingan ishlab chiqaruvchi-iste'molchi sxemasiga amal qiladi.
Ob'ekt sinfini aniqlash
Dizayn jarayonining ushbu bosqichida siz loyihalashayotgan tizimdagi muhim ob'ektlar haqida ba'zi fikrlarga ega bo'lishingiz kerak. Dizayn haqidagi tushunchangiz rivojlanib borishi bilan siz tizim ob'ektlari haqidagi ushbu g'oyalarni aniqlaysiz. Foydalanish holatlari tavsifi tizimdagi ob'ektlar va operatsiyalarni aniqlashga yordam beradi. Hisobot ob-havo ma'lumotlaridan foydalanish holatining tavsifidan ko'rinib turibdiki, ­ob-havo ma'lumotlarini yig'adigan asboblarni va ob-havo ma'lumotlarining xulosasini ifodalovchi ob'ektni ifodalovchi ob'ektlarni amalga oshirish kerak bo'ladi . Bundan tashqari, sizga odatda yuqori darajadagi tizim ob'ekti yoki foydalanish holatlarida belgilangan tizim o'zaro ta'sirini qamrab oluvchi ob'ektlar kerak bo'ladi. Ushbu ob'ektlarni hisobga olgan holda, siz tizimdagi umumiy ob'ekt sinflarini aniqlashni boshlashingiz mumkin.
1980-yillarda ob'ektga yo'naltirilgan dizayn rivojlanar ekan, ob'ektga yo'naltirilgan tizimlarda ob'ekt sinflarini aniqlashning turli usullari taklif qilindi:

1. 
   Quriladigan tizimning tabiiy til tavsifining grammatik tahlilidan foydalaning. Ob'ektlar va atributlar - otlar; operatsiyalar yoki xizmatlar fe'llardir (Abbott 1983).
   

Samolyot, menejer kabi rollar, so'rov kabi hodisalar, uchrashuvlar, joylar kabi o'zaro ta'sirlar kabi ilova domenidagi moddiy ob'ektlardan (narsalardan) foydalaning

2. 
   Tizimdan foydalanishning turli stsenariylari aniqlangan ­va navbatma-navbat tahlil qilinadigan stsenariy asosidagi tahlildan foydalaning. Har bir stsenariy tahlil qilinganda, tahlil uchun mas'ul bo'lgan guruh kerakli ob'ektlar, atributlar va operatsiyalarni aniqlashi kerak (Beck va Cunningham 1989).
   

Amalda, ob'ekt sinflarini ochish uchun bir nechta bilim manbalaridan foydalanish kerak. Tizimning norasmiy tavsifidan dastlab aniqlangan ob'ekt sinflari, atributlari va operatsiyalari dizayn uchun boshlang'ich nuqta bo'lishi mumkin. Ilova domeniga oid bilim yoki stsenariy tahlilidan olingan ma'lumotlar keyinchalik boshlang'ich ­ob'ektlarni takomillashtirish va kengaytirish uchun ishlatilishi mumkin. Ushbu ma'lumotni talablar hujjatlaridan, foydalanuvchilar bilan muhokamalardan yoki mavjud tizimlarni tahlil qilishdan to'plash mumkin. Tizimdan tashqaridagi ob'ektlarni ifodalovchi ob'ektlar bilan bir qatorda siz qidiruv va haqiqiylikni tekshirish kabi umumiy xizmatlarni taqdim etish uchun foydalaniladigan "amalga oshirish ob'ektlari" ni loyihalashingiz kerak bo'lishi mumkin.
Cho'l ob-havo stantsiyasida ob'ektni identifikatsiyalash tizimdagi moddiy jihozlarga asoslanadi. Bu yerga barcha tizim obyektlarini kiritish uchun menda joy yo‘q, lekin 7.6-rasmda men beshta obyekt sinfini ko‘rsatdim. Er termometri , Anemometr va Barometr ob'ektlari dastur domeni ob'ektlari bo'lib, WeatherStation va WeatherData ob'ektlari tizim tavsifi va stsenariy (foydalanish holati) tavsifidan aniqlangan:

1. 
   WeatherStation ob'ekt sinfi ob - havo stantsiyasining atrof-muhit bilan asosiy interfeysini ta'minlaydi . ­Uning operatsiyalari 7.3-rasmda ko'rsatilgan o'zaro ta'sirlarga asoslangan. Men bitta ob'ekt sinfidan foydalanaman va u ushbu o'zaro ta'sirlarning barchasini o'z ichiga oladi. Shu bilan bir qatorda, siz tizim interfeysini har bir o'zaro ta'sirda bitta sinfga ega bo'lgan bir nechta turli sinflar sifatida loyihalashingiz mumkin.
   
2. 
   WeatherData ob'ekt sinfi ob -havo hisoboti buyrug'ini qayta ishlash uchun javobgardir . U ob-havo ma'lumot tizimiga ob-havo stansiyasi asboblaridan olingan umumlashtirilgan ma'lumotlarni yuboradi.
   
3. 
   Tuproq termometri , Anemometr va Barometr ob'ekt sinflari tizimdagi asboblar bilan bevosita bog'liq. Ular tizimdagi moddiy apparat ob'ektlarini aks ettiradi va operatsiyalar ushbu uskunani boshqarish bilan bog'liq. Ushbu ob'ektlar belgilangan chastotada ma'lumotlarni yig'ish va to'plangan ma'lumotlarni mahalliy saqlash uchun avtonom ishlaydi. Ushbu ma'lumotlar so'rov bo'yicha WeatherData ob'ektiga yetkaziladi .
   

Siz boshqa ob'ektlar, atributlarni aniqlash uchun dastur domenidagi bilimlardan foydalanasiz. va xizmatlar:

1. 
   Ob-havo stantsiyalari ko'pincha uzoq joylarda joylashgan va ­ba'zida noto'g'ri bo'ladigan turli xil asboblarni o'z ichiga oladi. Asbobdagi nosozliklar haqida avtomatik ravishda xabar berilishi kerak. Bu asboblarning to'g'ri ishlashini tekshirish uchun sizga atributlar va operatsiyalar kerakligini anglatadi.
   
2. 
   Ko'p masofaviy ob-havo stantsiyalari mavjud, shuning uchun har bir ob-havo stantsiyasi o'z identifikatoriga ega bo'lishi kerak, shunda u aloqada noyob tarzda aniqlanishi mumkin.
   
3. 
   Ob-havo stantsiyalari turli vaqtlarda o'rnatilganligi sababli, asboblar turlari boshqacha bo'lishi mumkin. Shuning uchun, har bir asbob ham o'ziga xos tarzda identifikatsiya qilinishi va asboblar ma'lumotlarining ma'lumotlar bazasini saqlashi kerak.
   

ushbu ob'ektlar qanday amalga oshirilishi haqida o'ylamasdan , ob'ektlarning o'ziga e'tibor qaratishingiz kerak . Ob'ektlarni aniqlaganingizdan ­so'ng , siz ob'ekt dizaynini aniqlaysiz. Siz umumiy xususiyatlarni qidirasiz va keyin tizim uchun meros ierarxiyasini loyihalashtirasiz. Misol uchun, siz identifikator kabi barcha asboblarning umumiy xususiyatlarini belgilaydigan Instrument superklassini aniqlashingiz va olish va sinov operatsiyalarini bajarishingiz mumkin. Shuningdek, siz supersinfga yangi atributlar va operatsiyalarni qo'shishingiz mumkin, masalan, ma'lumotlar qanchalik tez-tez to'planishi kerakligini yozadigan atribut.
tizimdagi ob'ektlar yoki ob'ektlar sinflarini ko'rsatadi. Ular, shuningdek, ushbu ob'ektlar o'rtasidagi assotsiatsiya va munosabatlarni ko'rsatadi. Ushbu modellar tizim talablari va tizimni amalga oshirish o'rtasidagi ko'prikdir. Ular mavhum bo'lishi kerak, shunda keraksiz tafsilotlar ular va tizim talablari o'rtasidagi munosabatlarni yashirmaydi . ­Biroq, ular dasturchilarning amalga oshirish to'g'risida qaror qabul qilishlari uchun etarli tafsilotlarni ham o'z ichiga olishi kerak.
Biroq, agar rejaga asoslangan ishlab chiqish jarayoni ishlatilsa, sizga batafsilroq modellar kerak bo'lishi mumkin. Agar muhandislar, dizaynerlar va dasturchilar ­o'rtasidagi aloqalar bilvosita bo'lsa (masalan, tizim tashkilotning bir qismida loyihalashtirilsa, lekin boshqa joyda amalga oshirilsa), aloqa uchun dizaynning aniq tavsiflari kerak bo'ladi. Yuqori darajadagi mavhum modellardan olingan batafsil modellar barcha jamoa a'zolari dizayn haqida umumiy tushunchaga ega bo'lishi uchun foydalaniladi.
Shunday qilib, dizayn jarayonida muhim qadam, sizga kerak bo'lgan dizayn modellari va ushbu modellarda talab qilinadigan tafsilotlar darajasi to'g'risida qaror qabul qilishdir. Bu ishlab chiqilayotgan tizim turiga bog'liq. Ketma-ket ma'lumotlarni qayta ishlash tizimi o'rnatilgan real vaqt tizimidan ancha farq qiladi, shuning uchun siz har xil turdagi dizayn modellaridan foydalanishingiz kerak. UML 13 xil turdagi modellarni qo'llab-quvvatlaydi, lekin men 5 -bobda muhokama qilganimdek , bu modellarning ko'pchiligi keng qo'llanilmaydi. Ishlab chiqariladigan modellar sonini minimallashtirish dizayn xarajatlarini va dizayn jarayonini yakunlash uchun zarur bo'lgan vaqtni kamaytiradi.
Dizaynni ishlab chiqish uchun UML dan foydalansangiz, ikki turdagi dizayn modelini ishlab chiqishingiz kerak:

1. 
   Ob'ekt sinflari va ularning munosabatlaridan foydalangan holda tizimning statik tuzilishini tavsiflovchi tizimli modellar . Ushbu bosqichda hujjatlashtirilishi mumkin bo'lgan muhim munosabatlar umumlashtirish (meros) munosabatlari, foydalanish/foydalanish munosabatlari va kompozitsion munosabatlardir.
   
2. 
   Tizimning dinamik tuzilishini tavsiflovchi va tizim ob'ektlari o'rtasidagi kutilgan ish vaqti o'zaro ta'sirini ko'rsatadigan dinamik modellar . Hujjatlashtirilishi mumkin bo'lgan o'zaro ta'sirlar ob'ektlar tomonidan amalga oshirilgan xizmat so'rovlari ketma-ketligini va ushbu ob'ektlarning o'zaro ta'siri natijasida yuzaga keladigan holat o'zgarishlarini o'z ichiga oladi.
   

O'ylaymanki, uchta UML model turi, ayniqsa, foydalanish holatlari va arxitektura modellari uchun tafsilotlarni qo'shish uchun foydalidir:

1. 
   Ob'ektlarning mantiqiy guruhlarini izchil quyi ­tizimlarga ko'rsatadigan quyi tizim modellari . Ular har bir quyi tizim yopiq ob'ektlar bilan paket sifatida ko'rsatilgan sinf diagrammasi shaklida taqdim etiladi. Quyi tizim modellari strukturaviy modellardir.
   
2. 
   Ob'ektlarning o'zaro ta'siri ketma-ketligini ko'rsatadigan ketma-ketlik modellari . Ular UML ketma-ketligi yoki hamkorlik diagrammasi yordamida ifodalanadi. Ketma-ket modellar dinamik modellardir.
   
3. 
   Hodisalarga javoban ob'ektlar o'z holatini qanday o'zgartirishini ko'rsatadigan davlat mashinasi modellari . Ular UMLda holat diagrammalari yordamida ifodalanadi. Davlat mashinasi modellari dinamik modellardir.
   

Quyi tizim modeli - bu dizaynning mantiqiy bog'liq bo'lgan ob'ektlar guruhlariga qanday tashkil etilganligini ko'rsatadigan foydali statik model. Ob-havoni xaritalash tizimidagi quyi tizimlarni taqdim etish uchun men ushbu turdagi modelni allaqachon 7.4 -rasmda ko'rsatdim . Quyi tizim modellari bilan bir qatorda siz tizimlardagi ob'ektlar va ularning assotsiatsiyalarini (meroslash, umumlashtirish, yig'ish va boshqalar) ko'rsatadigan batafsil ob'ekt modellarini loyihalashingiz mumkin. Biroq, haddan tashqari murakkab modellashtirishda xavf mavjud. Tizim joriy etilgunga qadar qoldirilgan amalga oshirish haqida batafsil qarorlar qabul qilmasligingiz kerak .
Ketma-ket modellar - dinamik modellar bo'lib, ular har bir o'zaro ta'sir rejimi uchun sodir bo'ladigan ob'ektlarning o'zaro ta'sirlari ketma-ketligini tavsiflaydi. Dizaynni hujjatlashtirganda, har bir muhim shovqin uchun ketma-ketlik modelini ishlab chiqishingiz kerak. Agar siz ­foydalanish misoli modelini ishlab chiqqan bo'lsangiz, siz aniqlagan har bir foydalanish holati uchun ketma-ketlik modeli bo'lishi kerak.
7.7 -rasm UML ketma-ketlik diagrammasi sifatida ko'rsatilgan ketma-ketlik modelining namunasidir. Ushbu diagrammada tashqi tizim ob-havo stantsiyasidan jamlangan ma'lumotlarni so'raganda sodir bo'ladigan o'zaro ta'sirlar ketma-ketligini ko'rsatadi. Siz ketma-ketlik diagrammalarini yuqoridan pastgacha o'qiysiz:

1. 
   SatComms ob'ekti ob-havo ma'lumot tizimidan ob-havo stantsiyasidan ob-havo hisobotini yig'ish uchun so'rov oladi. U ushbu so'rovni qabul qilganligini tasdiqlaydi. Yuborilgan xabardagi strelka uchi tashqi tizim javobni kutmasligini, lekin boshqa ishlov berishni davom ettirishi mumkinligini ko'rsatadi.
   
2. 
   SatComms to'plangan ob-havo ma'lumotlarining xulosasini yaratish uchun sun'iy yo'ldosh orqali WeatherStation-ga xabar yuboradi. Shunga qaramay, tayoq o'qi SatComms javobni kutishni to'xtatmasligini ko'rsatadi.
   
3. 
   WeatherStation ob-havo ma'lumotlarini umumlashtirish uchun Commslink ob'ektiga xabar yuboradi. Bunday holda, strelka uchining kvadratchali uslubi WeatherStation ob'yekt sinfining namunasi javob kutishini bildiradi.
   
4. 
   Commslink WeatherData obyektidagi umumlashtirish usulini chaqiradi va javobni kutadi.