GOST 34.601-90 ga muvofiq “AS. Yaratish bosqichlari" AISni yaratishning quyidagi bosqichlarini belgilaydi, bu esa o'z navbatida bosqichlarga bo'linishi mumkin:

· AISga talablarni shakllantirish;

· AIS konsepsiyasini ishlab chiqish;

· texnik topshiriq;

· dastlabki dizayn;

· texnik loyiha;

· ish hujjatlari;

· ishga tushirish.

Har bir bosqichda o'ziga xos loyiha hujjatlari to'plami va tizimning texnik va dasturiy modullarini amalga oshirish mavjud. Amaliyot shuni ko'rsatadiki, tizimni yaratish jarayoni iterativ va bosqichma-bosqichdir. UML mualliflari kontseptsiyani belgilashda buni ta'kidlaydilar yagona dasturiy ta'minotni ishlab chiqish jarayoni va axborotni qo'llab-quvvatlash . Garchi birinchi bosqichda bir butun sifatida ASga qo'yiladigan talablar majmui shakllansa-da, aslida u har doim boshida to'liq bo'lmaydi va keyingi bosqichlarda aniqlashtiriladi. qilishim kerak iteratsiyalar, ya'ni alohida qadamlar va bosqichlarni to'liq yoki qisman takrorlash. Bundan tashqari, haqiqiy tizim ko'p funktsiyali va murakkabdir, shuning uchun u odatda quyi tizimlarga va alohida vazifalar to'plamiga bo'linadi, quyi tizimlar va birinchi bosqichning vazifalari, ikkinchisi va boshqalarni ajratib turadi. Tizim yaratilmoqda bosqichma-bosqich, dastlabki dizayn echimlarini foydalanuvchi talablariga yaxshiroq javob beradigan yanada rivojlanganlar bilan almashtirish bilan funksionallikni bosqichma-bosqich oshirish orqali. Bu kamaytiradi moliyaviy risklar yaratilishning yakuniy bosqichlarida vaqt va resurslar sarfini tejaydi.

AIS dasturiy ta'minoti va axborot ta'minotini yaratish uchun UML metodologiyasidan foydalanganda kelajakdagi tizimning statik va dinamik xususiyatlarini aks ettiruvchi bir-biriga bog'langan modellar to'plamini yaratish taklif etiladi:

· foydalanish namunasi;

· tahlil modeli;

· dizayn modeli;

· joylashtirish modeli;

· amalga oshirish modeli;

· sinov modeli.

Case Modelidan foydalaning foydalanish holatlari diagrammalarini va tegishli stsenariylarni o'z ichiga oladi, tizimning funktsional talablarini va foydalanuvchilar bilan o'zaro aloqada bo'lgan xatti-harakatlarini tavsiflaydi.

Tahlil modeli mantiqiy darajadagi foydalanish holatlarini amalga oshirish uchun umumiy sinf diagrammalarini, tegishli ketma-ketlik diagrammalarini va/yoki hamkorlik diagrammalarini o'z ichiga oladi va mantiqiy darajadagi foydalanish holatlari qanday amalga oshirilishining eskizidir.

Dizayn modeli tahlil modelining jismoniy amalga oshirilishining batafsil tasviri bo'lib, paket (quyi tizim) diagrammalarini, batafsil sinf diagrammalarini, ketma-ketlik diagrammalarini va/yoki hamkorlik diagrammalarini, holat diagrammalarini, turli darajadagi batafsillikdagi faoliyat diagrammalarini o'z ichiga oladi.

Joylashtirish modeli tizim ishlashi mumkin bo'lgan barcha tarmoq konfiguratsiyalarini aniqlaydigan dastlabki joylashtirish diagrammalarini o'z ichiga oladi. Joylashtirish sxemalari tarmoq tugunlarini, ulanish turlarini va faol tizim sinflarini tugunlar o'rtasida taqsimlashni ko'rsatadi.

Amalga oshirish modeli dizayn sinflari komponentlar sifatida qanday amalga oshirilishini tavsiflaydi. Shunga ko'ra, u komponent diagrammalarini, sinf (amalga oshirish) izlarini, batafsil joylashtirish diagrammalarini va tizim arxitekturasining tavsifini o'z ichiga oladi.

Sinov modeli test holatlari, sinov tartiblari va test komponentlarining tavsiflarini o'z ichiga oladi. U bajariladigan tizim komponentlarini sinash usullarini belgilaydi.

Modellarni qurish jarayonlarini AS yaratishning standartlashtirilgan bosqichlari bilan taqqoslaylik. Foydalanish namunasi AS uchun talablarni shakllantirish bosqichida qurilgan; tahlil modeli AS kontseptsiyasini ishlab chiqish bosqichida. Sahnada texnik topshiriq va dastlabki loyihalash, dizayn modeli quriladi. U texnik dizayn bosqichida takomillashtiriladi va joylashtirish modeli bilan to'ldiriladi. Ishchi hujjatlar bosqichida amalga oshirish va sinovdan o'tkazish modellari yaratiladi. Nihoyat, ishga tushirish bosqichida sinov modeli takomillashtiriladi va tizimning to'g'ri ishlashini davriy tekshirish va diagnostika qilish uchun mo'ljallangan ish paytida mos yozuvlar modeliga aylanadi.

1.5 UML tilining komponentlari

Yagona modellashtirish tili UML(Unified Modeling Language) - murakkab tizimlarni (jumladan, dasturiy ta'minot) ob'ektga yo'naltirilgan texnologiyadan foydalanish.

UML metodologiyasida AS yaratishda Hein/Sarson va SADT metodologiyalaridan ma'lum bo'lgan tizimli tizim tahlilining tamoyillari qo'llaniladi:

· yuqoridan pastga bosqichma-bosqich ishlab chiqish;

· diagramma tuzish texnikasi;

· tavsiflar ierarxiyasi;

· dizayn yechimlari tavsifini qat'iy rasmiylashtirish;

· loyihani texnik amalga oshirish tafsilotlarisiz mantiqiy darajada dastlabki ishlab chiqish;

· mijozning tizim dizaynini tushunishi uchun mavzu sohasi nuqtai nazaridan kontseptual modellashtirish;

· asboblar bilan texnologik yordam (CASE tizimlari).

Tizimdagi jarayonlar samaradorligining taxminiy tavsiflarini olish uchun UMLda murakkab tizim modeli o'rganilishi mumkin.

AS dasturiy ta'minotini o'rnatish, amalga oshirish va sinovdan o'tkazish modellari va UMLda axborotni qo'llab-quvvatlash, tanlangan dasturlash muhitlaridan birida keyinchalik avtomatlashtirilgan dastur kodini yaratish bilan amaliy loyiha sifatida ishlatilishi mumkin.

Murakkab tizimning etarlicha to'liq modeli ikkita jihatni aks ettirishi kerak:

-statik(strukturaviy) - tarkibiy qismlarning tarkibi, tuzilishi va ularning munosabatlari;

-dinamik(xulq-atvor) - tizimda sodir bo'ladigan yoki amalga oshirilishi kerak bo'lgan jarayonlarning mantiqiy tavsifi.

UML-da qabul qilingan modellarni aks ettirishning asosiy usuli bu matnli ma'lumotlar bilan ta'minlangan diagrammalar, shu jumladan OCL o'rnatilgan cheklash tilidagi ifodalar, shuningdek tizimni amalga oshirish uchun foydalaniladigan dasturlash va axborot so'rovlari tillari.

Modellashtirishning asosiy printsipi: tizim foydalanuvchi talablarini qondiradigan tarzda bir-biri bilan o'zaro ta'sir qiluvchi diskret ob'ektlar guruhi sifatida modellashtirilgan.

Statik model ob'ektlarning tuzilishini, turlarini va ob'ektlar orasidagi munosabatlarni belgilaydi. Dinamik model ob'ektlarning vaqt bo'yicha harakatlarini (ob'ektlar tarixi) va ularning o'zaro ta'sirini belgilaydi.

Asosan, UML diskret modellash tilidir, ya'ni u diskret hodisalar va holat o'zgarishlari tushunchasini o'z ichiga oladi. Uzluksiz jarayonlar taxminan diskretlashtirish orqali modellashtirilgan.

Model ikki jihatga ega: semantik axborot (semantika) va vizual tasvirlash (notatsiya).

UML tilidagi model ko'rinishlarining to'liq tarkibi 1-jadvalda keltirilgan

1-jadval – UMLda tizim modellarining ko'rinishi.

Tizimning eng keng tarqalgan kontseptual modeli foydalanish misoli diagrammasi bo'lib, u boshqa diagrammalarni qurish uchun boshlang'ich nuqtadir.

Barcha til diagrammalari qirralar (yoylar) bilan bog'langan uchlarini (geometrik raqamlarni) o'z ichiga olgan maxsus turdagi grafiklardir. Odatda tasvirning shkalasi va cho'qqilarning joylashuvi ayniqsa muhim emas, ammo ketma-ketlik diagrammasida vaqt o'qi kiritilgan va u erda u muhim ahamiyatga ega.

Bog'lanishlar tekislikda turli xil chiziqlar bilan ko'rsatilgan, raqamlar ichida matn yoziladi va ba'zi grafik belgilar cho'qqilar va ulanishlar yaqinida tasvirlanishi mumkin. UML kengaytmalari fazoviy diagrammalarga imkon beradi.

Tilda 4 turdagi grafik tuzilmalar mavjud:

· piktogrammalar (piktogrammalar);

· tekislikdagi grafik belgilar;

· yo'llar (chiziqlar);

· matn satrlari.

1.6 Kontseptual daraja. Case Modelidan foydalaning

Umuman olganda, ob'ektga yo'naltirilgan loyihalash jarayoni tizimli tizimlarni tahlil qilishning asosiy tamoyillariga muvofiq amalga oshiriladi: bizni bosqichma-bosqich darajadan bosqichga o'tkazadigan diagrammalar ierarxiyasini qurish bilan yuqoridan pastga loyihalash: kontseptual - mantiqiy - jismoniy (amalga oshirish)

Yuqori darajali diagramma OOSEda A. Jacobson tomonidan taklif qilingan diagramma hisoblanadi foydalanish diagrammasi bir butun sifatida tizimlar. Aynan shu tizimning dastlabki kontseptual ko'rinishi bo'lib, quyidagi maqsadlarda qurilgan:

· modellashtirilgan fan sohasining umumiy chegaralari va kontekstini aniqlash;

· shakl Umumiy talablar tizimning funktsional harakati va interfeysiga;

· dasturchilar va mijozlar - tizim foydalanuvchilari o'rtasidagi o'zaro munosabatlar uchun dastlabki hujjatlarni tayyorlash.

Modelning nuqtai nazari: tizimning tashqi foydalanuvchisi. Foydalanish diagrammasi aktyorlar, foydalanish holatlari va assotsiatsiyalarni o'z ichiga oladi.

Faol(aktyor, tashqi ob'ekt, aktyor) - tizim, quyi tizim yoki sinf bilan bevosita o'zaro ta'sir qiluvchi xabar manbalari/qabul qiluvchilar sinfining mavhum tavsifi. Bu tavsif rollar foydalanuvchi (shaxs yoki boshqa tizim, quyi tizim, sinf) tizim bilan o'zaro aloqada o'ynagan. Aslida, bu ma'lum bir talabni talab qiladigan tizimga o'xshash ma'lumot so'rovlarining umumlashtirilishi xizmat(xizmatlar).

Aktent aniq bir narsa bilan aniqlanishi shart emas shaxs yoki qurilma, garchi ular faqat bitta rolni bajarsa, bu printsipial jihatdan ba'zan mumkin. Ko'pincha - jismoniy - bu turli odamlar va bir xil xizmatni olish uchun tizimga kiradigan qurilmalar. Eng yuqori darajada, masalan, aktantlar operator, tizim administratori, ma'lumotlar bazasi ma'muri, oddiy foydalanuvchi yoki ba'zi qurilmalar sinfi bo'lishi mumkin.

Barcha mumkin bo'lgan faol moddalar foydalanuvchining tizim bilan o'zaro ta'sirining barcha mumkin bo'lgan usullarini (quyi tizim, sinf) ishlatadi. Tizimni amalga oshirishda faollar odamlar va jismoniy ob'ektlarda mujassamlanadi. Bir kishi yoki jismoniy ob'ekt, o'zaro ta'sir qilish usuliga qarab, bir nechta aktantlarni (turli rollarni) ifodalashi mumkin. Masalan, bitta shaxs operator va ma'lumotlar bazasi ma'muri, sotuvchi va xaridor va boshqalar bo'lishi mumkin.

Ko'pgina ASlarda odamlardan tashqari boshqa aktyorlar yo'q. Biroq, faollar tashqi tizim, kiritish-chiqarish qurilmasi yoki taymer bo'lishi mumkin (ko'pincha o'rnatilgan real vaqt tizimlarida mavjud). Foydalanish holatidagi aktantlar orasida biri alohida ajralib turadi asosiy aktyor(asosiy aktyor), tizim bilan ishlashni boshlaydi. Qolganlari ikkinchi darajali bo'lib, ular ham foydalanish jarayonida ishtirok etadilar, natijalarni oladilar va ba'zi bir oraliq ma'lumotlarni kiritadilar.

Mantiqiy va fizik darajalarda faollar sinflar misollari bo'lgan sinflar va ob'ektlar bilan ifodalanadi. Ajdod aktantiga ega bo'lgan barcha rollar va munosabatlar, atributlar va operatsiyalarni meros qilib olgan holda, aktantlar ierarxiyasini qurish mumkin. Ajdod aktantining misoli har doim tizimdagi ajdod aktantidan foydalanish e'lon qilingan joyda ishlatilishi mumkin (almashtirish printsipi).

Aktsiyani diagrammalarda ikki shaklda ko'rsatish mumkin:

3. Stereotipning ichki belgisi bilan sinf belgisi (to'rtburchak).

4. Ko'proq standart: yozuvli "odam" (odamning ramzi)

Aktiv tizimdan tashqarida va uning ichki tuzilishi aniqlanmagan. Bu xabarlarning manbai/qabul qiluvchisi.

Mijoz

Foydalanish holati(pretsedent, foydalanish holati) - aktantga uning so'rovlariga javoban taqdim etiladigan xizmat sinfining (xizmat funktsiyalarining) mavhum tavsifi.

Xizmat butun tizim, quyi tizim yoki sinf tomonidan taqdim etilishi mumkin. Shunday qilib, foydalanish holati tizim funksionalligi yoki xatti-harakatlarining ba'zi qismini modellashtirishni anglatadi. Foydalanish holati nomga ega va tashqi manba/qabul qiluvchiga (aktant) ko'rinadigan muayyan harakatlar ketma-ketligini bildiradi. Variantni amalga oshirishning ichki usuli yashirin va quyi darajadagi tafsilotlarda namoyon bo'ladi. hamkorlik diagrammasi. Har qanday sinf singari, foydalanish holatida ham atributlar va operatsiyalar mavjud bo'lib, ularning bajarilishi jismoniy qatlamda namoyon bo'ladi.

Foydalanish holati aktant tizim (quyi tizim, sinf) bilan boshlanadigan va tugaydigan xabarlarning butun ketma-ketligini o'z ichiga oladi. Shuning uchun, foydalanish holatlarini amalga oshirishning har qanday misoli har doim vaqt bo'yicha boshlanishi va hech bir faol ushbu parametr uchun xabar yubormaganda tugashiga ega. Bunga xato xabarlari, turli xil sozlamalar (alternativlar) bilan texnik xizmat ko'rsatish funksiyasini bajarish variantlari ham kiradi.

Foydalanish misoli - bu aktant instantsiyasidan birinchi xabar olgandan keyin boshlanadigan foydalanish holatining bajarilishi. Berilgan xabarga javoban, foydalanish holati muayyan harakatlar ketma-ketligini bajaradi, masalan, aktantning boshqa misollariga (nafaqat muallifga) xabar yuborish. O'z navbatida, ushbu faollar ushbu foydalanish misoliga xabarlar yuboradilar va o'zaro aloqa boshqa bunday xabarlar olinmaguncha davom etadi. Bu foydalanish holatining tugashini bildiradi.

Aktent va foydalanish holati o'rtasidagi munosabat ko'rsatilgan uyushma.

Diagrammada foydalanish holati ikki shaklda tasvirlangan:

1) ellips, ichiga ism qo'yiladi

2) to'rtburchak - har qanday sinf kabi

Mijoz

Sensor

Aktyorlar va foydalanish holatlari o'rtasida assotsiatsiya ulanishning yagona turi hisoblanadi. Bundan tashqari, u semantikaga ega kommutatsiya aloqalari, ya'ni xabarni uzatish odatda belgilanmaydi, chunki kontekst aktant va foydalanish holatlari belgisidan aniq. Ammo siz uni belgilashingiz, shuningdek ulanishning ko'pligini ko'rsatishingiz mumkin:

Bank mijozi

Ko'plik(ko'plik) berilgan ulanishda ishtirok etuvchi sinfning o'ziga xos misollari sonini tavsiflaydi (bitta mijoz cheklanmagan miqdordagi kreditlar berishi mumkin).

Umuman uyushma ikki yoki undan ortiq model komponentlari o'rtasidagi munosabatdir. Aksariyat hollarda komponentlar ob'ektlarning ba'zi sinflari bo'lganligi sababli, assotsiatsiya namunasi shunchaki birlashma atributlari (xususiyatlari) bilan jihozlangan muayyan misollarga havolalarning tartiblangan ro'yxatidir.

Assotsiatsiya nomi, agar mavjud bo'lsa, noyob bo'lishi kerak. U assotsiatsiya ishtirokchilari bo'lgan sinflar o'rtasidagi munosabatlarning ma'nosiga ko'ra shakllanadi. Masalan, "Xodim da ishlaydi Bo'lim", "Menejer yakunlaydi Kompyuter" va boshqalar.

Uyushmalar o'zlari sinflar ( assotsiatsiya sinfi, assotsiatsiya sinfi), u ham sinf, ham assotsiatsiya xususiyatlariga ega. Bu sinfning misollari faqat ob'ektlarga havolalar emas, balki atribut (xususiyat) qiymatlariga ham ega bo'lgan ulanishlardir.

Uyushma a'zolari uning deyiladi qutblar. Barcha qutblar ulanishda ishtirok etgan sinflarning rollari bo'lib, ular alohida va ba'zi tartiblangan ro'yxatda keltirilgan bo'lishi mumkin. Aksariyat hollarda assotsiatsiyalar ikkilik (muayyan semantika bilan assotsiatsiyada ikkita rol) bo'ladi, lekin ular ham bo'lishi mumkin. n -ary. Bitta va bir xil sinf turli rollarda harakat qilishi mumkin, ya'ni bir vaqtning o'zida birlashmaning ikkita qutbida bo'lishi mumkin.

Ulanishlarning ko'pligi qutblarda ko'rsatilgan.

Tizimning ishlashi davomida ulanishlar paydo bo'lishi va yo'qolishi mumkin, cheklovlar va tegishli predikatlar assotsiatsiya qutblarida belgilanishi mumkin.

Ba'zan ulanish faqat qutblardan birida o'zgaradi. Agar havolaning atributlari bo'lsa, ular operatsiyalar orqali o'zgartirilishi mumkin, ammo havola ishtirokchilariga havolalar o'zgarmaydi.

Assotsiatsiya 2 ta sinf chegaralarini birlashtiruvchi uzluksiz chiziq sifatida tasvirlangan, agar assotsiatsiya n-ary, keyin romb chiziladi (birikish belgisi):

		Ko'p uyushmalar - yig'ish
	Ikkilik assotsiatsiya

Foydalanish holatlari bir-biri bilan xabar almashmaydi va faqat munosabatlarda (bog'lanish) bo'lishi mumkin. kengaytmalar(uzaytirish) kiritish(shu jumladan) va umumlashtirishlar(umumlashtirish).

IN kengaytirish haqida foydalanish holati - mijoz asosiy ketma-ketlikning qaysidir nuqtasidan boshlab qo'shimcha harakatlar ketma-ketligini kiritadi va bir nechta bunday "qo'shimchalar" bo'lishi mumkin. Bu nuqtalarning barchasi deyiladi kengaytirish nuqtalari.

Birlashtirilgan jarayon Rational (Rational Unified Process, RUP) tomonidan ishlab chiqilgan - bu miqdor har xil turlari foydalanuvchi talablarini dasturiy ta'minot tizimiga aylantirish uchun zarur bo'lgan tadbirlar, . Uning mavhum va batafsil tasviri rasmda ko'rsatilgan. 7.2.

RUPning asosiy tushunchalari artefakt va pretsedentdir. Artefaktlar- Bular yakuniy dasturiy mahsulot ustida ishlayotganda ishlab chiqariladigan yoki loyihada foydalaniladigan loyihaning ba'zi mahsulotlari. Pretsedentlar yoki foydalanish holatlari(foydalanish holati) ‑ Bu kuzatilishi mumkin bo'lgan natijani yaratish uchun dasturiy ta'minot tizimi tomonidan bajariladigan harakatlar ketma-ketligi.

Dasturiy ta'minot tizimini ishlab chiqishning butun jarayoni RUP sifatida ko'rib chiqiladi artefakt yaratish jarayoni. Bundan tashqari, oxirgi foydalanuvchining qo'liga tushadigan narsa, u dasturiy modul yoki dasturiy ta'minot hujjatlari bo'ladimi, barcha loyiha artefaktlarining kichik sinflaridan biridir.

Loyiha jamoasining har bir a'zosi o'z artefaktlarini yaratadi va ular uchun javobgardir. Dasturchi dasturni ishlab chiqadi, menejer loyiha rejasini ishlab chiqadi va tahlilchi tizim modelini ishlab chiqadi. RUP qachon, kim tomonidan va qanday artefakt yaratish kerakligini aniqlash imkonini beradi.

(A)

Guruch. 7.2. Yagona dasturiy ta'minotni ishlab chiqish jarayoni ( A- mavhum tasvirlash, b- asosiyning batafsil taqdimoti RUP jarayonlari)

Biroq, RUP bitta jarayondan ko'ra ko'proq; bu keng ko'lamli dasturiy ta'minot tizimlari, dastur sohalari, malaka darajalari va loyiha o'lchamlari uchun ixtisoslashtirilgan umumlashtirilgan jarayon asosidir. RUP - komponentlarga yo'naltirilgan. Bu yaratilgan degan ma'noni anglatadi dasturiy ta'minot tizimi aniq belgilangan interfeyslar bilan bog'langan dasturiy komponentlar asosida qurilgan.

Dasturiy ta'minot tizimining grafik tasvirlarini (modellarini) ishlab chiqish uchun RUP dan foydalanadi Yagona modellashtirish tili(UML) . Aslida, UML RUP ning ajralmas qismidir - ular birgalikda ishlab chiqilgan.

Biroq, RUP jarayonining haqiqatan ham o'ziga xos jihatlari uchta iborada yotadi - foydalanish holiga asoslangan, arxitekturaga yo'naltirilgan, iterativ va ortib boruvchi. Bu Yagona jarayonni noyob qiladi.

RUPda dasturiy ta'minot tizimining to'liq ko'rinishi dasturiy ta'minot tizimini vizualizatsiya qilish, spetsifikatsiya qilish, loyihalash va hujjatlashtirish bo'yicha barcha muhim qarorlarni qamrab oluvchi to'qqiz modelni o'z ichiga oladi (7.3-rasm):

1. biznes jarayoni modeli, bu tashkilotning mavhumligini rasmiylashtiradi (boshqaruv tizimidan foydalanishning barcha variantlari va ularning foydalanuvchilar bilan aloqalari bilan);

2. modeldan foydalaning- tizimga qo'yiladigan funksional talablarni rasmiylashtiradi;

3. domen modeli yoki biznes modeli, tizim kontekstini tavsiflovchi.

4. tahlil modeli, bu ikkita maqsadga ega - foydalanish holatlari tafsilotlarini aniqlashtirish va tizim xatti-harakatlarini ta'minlaydigan ob'ektlar to'plami bo'yicha birlamchi taqsimlashni yaratish. turli xil variantlar xulq-atvor;

5. jarayon modeli(ixtiyoriy) - tizimda parallellik va sinxronizatsiya mexanizmlarini rasmiylashtiradi;

6. dizayn modeli, belgilaydi: ( A) - tizimning statik tuzilishi, masalan, quyi tizimlar, sinflar va interfeyslar va ( b) - shaklda amalga oshirilgan holatlardan foydalanish hamkorliklar quyi tizimlar, sinflar va interfeyslar o'rtasida;

7. amalga oshirish modeli, bu komponentlarni (manba kodi bilan ifodalangan) va komponentlar bo'yicha sinflar tartibini o'z ichiga oladi;

8. joylashtirish modeli, bu jismoniy kompyuterlarni belgilaydi - tarmoq tugunlari va ushbu tugunlar bo'ylab komponentlarning joylashuvi;

9. sinov modeli, foydalanish holatlarini tasdiqlash uchun sinov holatlarini tavsiflaydi;

Guruch. 7.3. RUP modellari (tegishli UML diagrammalari shaklida)
va ularning aloqalari,

Ushbu modellarning barchasi ulangan. Ular birgalikda dasturiy ta'minot tizimini to'liq tavsiflaydi. Bitta modelning elementlari boshqa modellar bilan bog'lanish orqali tashkil etilgan oldinga va orqaga qarab kuzatishga bog'liq (7.3-rasmga qarang). Masalan, foydalanish holati (foydalanish modelida) mos keladigan foydalanish holatlarini amalga oshirish (dizayn modelida) va test misolida (sinov modelida) kuzatilishi mumkin. Kuzatish tushunish va o'zgartirish kiritishni osonlashtiradi. RUP ishlab chiqish jarayonida yaratilgan UML diagrammalari dasturiy mahsulot haqida to'liq tasavvur beradi).

RUPda asosiy e'tibor hujjatlarni tayyorlashga emas, balki shunga qaratilgan modellashtirish ishlab chiqilayotgan tizim. Modellar muammoni ham, uni hal qilish yo'llarini ham aniqlashga yordam beradi va ular uzoq vaqtdan beri murakkab tizimlarni tavsiflashning de-fakto standartiga aylangan va ishlab chiquvchilarga har qanday dasturiy ta'minot tizimlarining artefaktlarini aniqlash, vizualizatsiya qilish, qurish va hujjatlashtirish imkonini beradigan UML tilidan foydalangan holda yaratilgan. murakkablik.

Rational Unified Process (RUP) - Rational Software tomonidan yaratilgan eng yaxshi dasturiy ta'minot ishlab chiqish metodologiyalaridan biri. Ko'pgina muvaffaqiyatli dasturiy ta'minot loyihalari tajribasiga asoslanib, Yagona jarayon sanoatni rivojlantirish usullariga asoslangan murakkab dasturiy ta'minot tizimlarini yaratishga imkon beradi. RUP tayanadigan asosiy ustunlardan biri bu Yagona modellashtirish tili (UML) yordamida modellarni yaratish jarayonidir. Ushbu maqola Rational Software metodologiyasidan foydalangan holda dasturiy ta'minot tizimlarini ishlab chiqish ish jarayonida UML diagrammalaridan foydalanish haqida.

Hech kimga sir emaski, dasturiy ta'minotni yaratish murakkab jarayon bo'lib, u bir tomondan ijodkorlik bilan ko'p umumiyliklarga ega bo'lsa, ikkinchi tomondan, bu juda daromadli bo'lsa-da, ayni paytda qimmat biznesdir. Bozordagi shiddatli raqobat ishlab chiquvchilarni ko'proq izlashga majbur qiladi samarali usullar ish. Dasturiy ta'minot tizimlarini yaratish yo'llari yanada ko'proq Qisqa vaqt, kamroq xarajat va eng yaxshi sifat. Dasturlarning murakkabligi doimiy ravishda oshib bormoqda. Yaqin vaqtgacha dasturiy mahsulotlarni jismoniy shaxslar tomonidan yoki, masalan, avtomatlashtirilgan korxonaning IT bo'limida yaqin vaqt ichida yaratish mumkin edi.

Hozirgi vaqtda tizzada dasturlar yaratadigan shaxslar kichik kommunal xizmatlar va "og'ir" dasturiy mahsulotlar uchun turli xil kengaytmalar modullari bilan qolmoqda. Kelajak dasturiy ta'minotni yaratishga sanoat yondashuviga tegishli. 1913 yilda Genri Ford birinchi avtomobil yig'ish liniyasini ishga tushirdi va 90-yillarda xuddi shunday yig'ish liniyasi IT texnologiyalari sohasida qo'llanila boshlandi. Jamoani rivojlantirish butunlay boshqacha yondashuvni va ertami-kechmi yaratilishi kerak bo'lgan boshqa metodologiyani talab qiladi.

Rational Software Corporation (http://www.rational.com) deyarli har qanday dasturiy mahsulotni yaratish uchun keng qamrovli tavsiyalar to'plami bo'lgan Rational Unified Process (RUP) deb nomlangan tuzilgan bilimlar bazasini chiqardi. Eng yaxshi ishlanmalar tajribasini o'zlashtirgan RUP, dasturiy ta'minot tizimini o'z vaqtida, ma'lum bir funksionallik va ajratilgan byudjet doirasida tugatish uchun loyihada qachon, kim va nima qilish kerakligini batafsil aytib beradi.

Birlashtirilgan jarayonni mijozlar talablarini dasturiy ta'minot tizimiga aylantirish uchun zarur bo'lgan ishlab chiquvchi kompaniyaning turli xil faoliyati yig'indisi sifatida ko'rib chiqish mumkin. Foydalanuvchilarga "mazmunli natijalar" beradigan va ular tizimdan kutganlarini bajaradigan tizim. Shuning uchun jarayon tizimdan foydalanish holatlari yoki boshqacha tarzda - pretsedentlar bilan boshqariladi.

Mijozlarning talablarini o'z vaqtida amalga oshirish uchun Yagona jarayon iteratsiyalardan iborat bosqichlarga bo'linadi, shuning uchun jarayon iterativ va qo'shimcha deb ataladi. Har bir iteratsiya asosiy ish tsiklidan o'tadi va ishlab chiquvchilarni yakuniy maqsadga olib keladi: dasturiy ta'minot tizimini yaratish. Takrorlashlar davomida loyihani muvaffaqiyatli yakunlash uchun zarur bo'lgan oraliq artefaktlar va ma'lum funktsiyalar to'plamini amalga oshiradigan dasturiy ta'minot tizimining versiyasi yaratiladi, bu iteratsiyadan iteratsiyagacha ortadi. Jarayonning bosqichlari va asosiy ish oqimlari rasmda ko'rsatilgan. 1, u erda bosqichma-bosqich ishning taxminiy mehnat xarajatlari ham berilgan.

guruch. 1 RUP bosqichlari va ish oqimlari

Shuni ta'kidlash kerakki, rasmda. 1-rasmda faqat Yagona jarayonning asosiy ishi ko'rsatilgan. Misol uchun, diagrammani chalkashtirmaslik uchun faoliyatni boshqarish faoliyati bu erda ko'rsatilmagan.

Barcha dasturiy ta'minotni ishlab chiqish RUPda artefaktlarni yaratish jarayoni sifatida ko'rib chiqiladi. Loyihaning har qanday natijasi, xoh u manba matnlari, xoh ob'ekt modullari, foydalanuvchiga uzatiladigan hujjatlar, modellar - bu barcha loyiha artefaktlarining kichik sinflari. Loyiha jamoasining har bir a'zosi o'z artefaktlarini yaratadi va ular uchun javobgardir. Dasturchi dasturni, menejer loyiha rejasini, tahlilchi esa tizim modelini yaratadi. RUP qachon, kim tomonidan va qanday artefakt yaratilishi, o'zgartirilishi yoki ishlatilishi kerakligini aniqlash imkonini beradi.

Loyiha artefaktlarining eng qiziqarli sinflaridan biri bu modellar bo'lib, ular ishlab chiquvchilarga dasturiy ta'minot tizimi artefaktlarini aniqlash, vizualizatsiya qilish, qurish va hujjatlashtirish imkonini beradi. Har bir model ishlab chiqilayotgan tizimning o'ziga xos ko'rinishi bo'lib, muammolarni tasvirlash va yechimlarni taklif qilish uchun mo'ljallangan. Modellarning o'zini-o'zi ta'minlashi analitik yoki ishlab chiquvchining boshqa manbalarga murojaat qilmasdan, ma'lum bir modeldan o'ziga kerakli barcha ma'lumotlarni olishi mumkinligini anglatadi.

Modellar kelajakdagi tizimni, uning ob'ektlarini va ularning o'zaro ta'sirini rivojlanishga katta mablag 'sarflashdan oldin ham ko'rib chiqishga imkon beradi; ular kelajakdagi foydalanuvchilarning tashqi tomondan va ishlab chiquvchilarning ko'zlari bilan, hatto manbaning birinchi qatoridan oldin ham ko'rishga imkon beradi. kod yaratiladi. Aksariyat modellar UML diagrammalari bilan ifodalanadi, siz UML haqida ko'proq ma'lumot olishingiz mumkin, masalan.

Yagona modellashtirish tili 80-yillarning oxiri va 90-yillarning boshlarida, asosan, "uch do'st" Gradi Bucha, Jim Rembo va Ivar Jeykobsonning sa'y-harakatlari tufayli paydo bo'ldi. Endi u OMG konsorsiumi tomonidan standart modellashtirish tili sifatida qabul qilingan bo'lib, u ishlab chiquvchilarga modellarni loyihadagi har bir kishi tomonidan umumiy qabul qilingan va tushunarli bo'lgan grafik elementlarda ko'rsatishga imkon beruvchi aniq belgi bilan ta'minlaydi.

Ammo shuni unutmasligimiz kerakki, modellashtirish tili faqat yozuvni ta'minlaydi - tizimni tavsiflash va modellashtirish vositasi va birlashtirilgan jarayon ushbu vositadan foydalanish metodologiyasini, shuningdek Rationalning boshqa metodologiyasini qo'llab-quvvatlash vositalarini belgilaydi. UML dan ma'lum bir metodologiyasiz foydalanish mumkin, chunki u jarayondan mustaqil va qaysi jarayon opsiyasi qo'llanilishidan qat'i nazar, ishlab chiqish jarayonida qabul qilingan qarorlarni hujjatlashtirish va yaratilgan modellarni ko'rsatish uchun diagrammalardan foydalanishingiz mumkin.

Dasturiy ta'minot tizimi dasturchilar uchun yangi texnologiyalarni sinab ko'rish va loyiha menejeri uchun tajriba orttirish uchun emas, balki foydalanuvchining muayyan muammolarini hal qilish uchun yaratilgan. Umuman olganda, ishlab chiqish jarayonida ob'ektga yo'naltirilgan yondashuv, UML, RUP dan foydalanasizmi yoki XP (ekstremal dasturlash) usulidan foydalangan holda tizim yaratasizmi, foydalanuvchining ahamiyati yo'q. Muayyan usullardan, texnologiyalardan foydalanish va loyihaning optimal ichki tuzilishini yaratish ishlab chiquvchilarning vijdoniga bog'liq bo'lib, ular oldingi tajriba va o'z xohishlariga ko'ra qaror qabul qiladilar. Biroq, foydalanuvchi o'z talablarini e'tiborsiz qoldirganingizni kechirmaydi. Dasturiy ta’minot tizimi eng ilg‘or uslub va texnologiyalar yordamida o‘n marta ishlab chiqilgan bo‘lsa ham, foydalanuvchi undan “mazmunli natija” deb atalmagan natijani ololmasa, dasturiy ta’minot loyihangiz ayanchli tarzda barbod bo‘ladi.

Bundan kelib chiqadiki, UML-ni o'ylamasdan qo'llash, moda bo'lgani uchun, nafaqat rivojlanishni muvaffaqiyatga olib keladi, balki katta hajmdagi qo'shimcha adabiyotlarni o'rganishi kerak bo'lgan xodimlar va loyiha menejerlari orasida norozilikni keltirib chiqarishi mumkin. loyiha bo'yicha mehnat xarajatlari oshadi va daromadlar o'smaydi. Ushbu texnologiyani amalga oshirishdan nimani olishni xohlayotganingizni aniq tushunishingiz va ushbu maqsadga amal qilishingiz kerak. UML-dan foydalanish ishlab chiqish resurslarini tejaydi, chunki bu tizim haqida tasavvurga ega bo'lish uchun sxemalar va prototiplarni yaratishdan ko'ra tezroq, beqiyos kamroq resurslarni sarflashga imkon beradi.

Diagrammalar loyiha a'zolarining bir-biri bilan muloqot qilishlarini osonlashtiradi va ayniqsa qimmatli bo'lgan narsa tizimning oxirgi foydalanuvchilarini jarayonga jalb qiladi. Modellashtirish sizga loyiha xatarlarini kamaytirishga imkon beradi, chunki dasturchilar uchun noaniq natijaga borishdan ko'ra aniq va tushunarli narsalarni qilish har doim osonroqdir. Diagrammalarni yaratish qurilishda loyihani yaratishga o'xshaydi - siz usiz ham qilishingiz mumkin, masalan, yozgi uyda shiypon qurishda, ammo bino qanchalik katta bo'lsa (bizning holatlarimizda). dasturiy ta'minot), buni qilish qanchalik qiyin bo'lsa va yakuniy natija shunchalik noaniq bo'ladi.

Bir marta men o'n yil davomida bozorda ancha muvaffaqiyatli bo'lgan, lekin ish jarayonida modellashtirishdan umuman foydalanmagan, balki prototiplarga asoslangan dasturiy ta'minot kompaniyasida RUP bo'yicha seminar o'tkazganman. Zalda yigirmaga yaqin yosh va tajribali dasturchilar yig'ildi, ular RUP va UML haqida aytganlarimni diqqat bilan tinglashdi. Ulardan biri misol diagrammalari bilan qoplangan taxtaga qarab shunday dedi: "Bularning barchasi qiziqarli va ehtimol boshqa loyihalar uchun yaxshidir," dedi u, "lekin biz bularning barchasisiz ancha vaqtdan beri ishlayapmiz, chunki biz Biz hali ham UMLsiz boshqardik, ehtimol bizga kerak emas.

Bu savol meni dasturiy ta'minot ishlab chiqaruvchi kompaniyada RUP va UML ni joriy qilishda muqarrar ravishda ro'y berishi kerak bo'lgan biznes jarayonlaridagi o'zgarish sanoat korxonasida axborot tizimini joriy qilish kabi qiyin bo'lishi mumkin degan fikrni uyg'otdi.Har qanday amalga oshirish stereotiplarni buzishdir. Dasturiy ta'minotni ishlab chiquvchi kompaniya xodimlarining malakasi ancha yuqori bo'lganligi sababli, bunday odamlar uchun "oddiy odamlarga" qaraganda o'z qarashlaridan voz kechish qiyinroq va yuzaga keladigan qiyinchiliklar va rad etishni protsessualdan ob'ektga o'tish bilan taqqoslash mumkin. yo'naltirilgan fikrlash.

1.Talablar ta'rifi

Birlashtirilgan jarayon - bu foydalanuvchilarning o'zaro ta'siri stsenariylarini aks ettiruvchi foydalanish holatlariga asoslangan jarayon. Aslida, bu foydalanuvchilarning dasturiy ta'minot tizimiga tashqi ko'rinishi. Shunday qilib, RUP ma'lumotlariga ko'ra, rivojlanishning eng muhim bosqichlaridan biri faqat foydalanuvchilar va tahlilchilarning xayoliga kelishi mumkin bo'lgan tizimning ishlashi uchun barcha mumkin bo'lgan istaklarni to'plashdan iborat bo'lgan talablarni aniqlash bosqichi bo'ladi. Keyinchalik, bu ma'lumotlarni tizimlashtirish va tizimlashtirish kerak bo'ladi, ammo bu bosqichda foydalanuvchilar bilan suhbatlar va hujjatlarni o'rganish orqali tahlilchilar kelajakdagi tizim uchun iloji boricha ko'proq talablarni to'plashlari kerak, bu birinchi qarashda ko'rinadigan darajada oddiy emas. Foydalanuvchilar ko'pincha oxirida nima olishlari kerakligini bilishmaydi. Ushbu jarayonni osonlashtirish uchun tahlilchilar foydalanish holatlari diagrammalaridan foydalanadilar (2-rasm).

2-rasm. Foydalanish misoli diagrammasiga misol

Diagramma - bu tizim bilan o'zaro aloqada bo'lgan aktyorlar (aktantlar) va dasturiy ta'minot ob'ektlarining ularning harakatlariga reaktsiyasi. Aktyorlar ham foydalanuvchilar, ham axborotni uzatishi yoki qabul qilishi kerak bo'lgan tashqi agentlar bo'lishi mumkin. Foydalanish holati belgisi tizimning tashqi kiritishga munosabatini aks ettiradi va faol uchun nima qilish kerakligini ko'rsatadi.

Muayyan foydalanish holatini batafsil bayon qilish uchun faoliyat diagrammasi qo'llaniladi, uning misoli 3-rasmda keltirilgan.

guruch. 3 Faoliyat diagrammasiga misol

Foydalanish diagrammasining soddaligi tahlilchilarga talablarni aniqlash jarayonida mijozlar bilan oson muloqot qilish imkonini beradi, tizimga qo'yiladigan cheklovlarni va individual talablarni amalga oshirishda, masalan, tizimning javob vaqti, keyinchalik ular ishlamaydigan bo'limga kiradi. talablar.

Foydalanish diagrammasi test stsenariylarini yaratish uchun ham ishlatilishi mumkin, chunki foydalanuvchilar va tizim o'rtasidagi barcha o'zaro aloqalar allaqachon aniqlangan.

Talablarni to'g'ri aniqlash uchun ishlab chiquvchilar kelajakdagi tizim ishlaydigan kontekstni (mavzu sohasining bir qismini) tushunishlari kerak. Buning uchun domen modeli va biznes modeli yaratiladi, ular bir xil masalaga turlicha yondashuvlardir. Ko'pincha bitta narsa yaratiladi: domen modeli yoki biznes modeli.

Ushbu modellar orasidagi farq shundaki, domen modeli tizim ishlaydigan muhim tushunchalarni va ularning bir-biri bilan aloqalarini tavsiflaydi. Holbuki, biznes modeli tizim qo'llab-quvvatlashi kerak bo'lgan biznes jarayonlarini (mavjud yoki kelajak) tavsiflaydi. Shu sababli, ushbu model jarayonga jalb qilingan biznes ob'ektlarini belgilashdan tashqari, ishchilarni, ularning mas'uliyatini va ular bajarishi kerak bo'lgan harakatlarini belgilaydi.

Domen modelini yaratish uchun oddiy sinf diagrammasi qo'llaniladi (6-rasm), lekin biznes modelini yaratish uchun bu etarli emasligi aniq. Bunday holda, biznes-jarayonlarning mohiyatini aks ettiruvchi qo'shimcha piktogrammalardan foydalangan holda foydalanish diagrammasi qo'llaniladi - bular tadbirkorlik sub'ekti, biznesdan foydalanish holati, tadbirkorlik sub'ekti va biznes boshqaruvi. Bu model ishlab chiqish jarayonida yaratilgan keyingi model - tahlil modeliga ancha yaqinroq.

2. Tahlil

Tizimning ishlashi uchun talablar va kontekstni aniqlagandan so'ng, olingan ma'lumotlarni tahlil qilish vaqti keldi. Tahlil jarayonida ishlab chiquvchilarni kelajakdagi tizim arxitekturasiga yo'naltiradigan analitik model yaratiladi. Analitik model - tizimning tashqi ko'rinishini ko'rsatadigan foydalanish misolidan farqli o'laroq, tizimning ichkaridan ko'rinishi.

Ushbu model sizga tizimni qanday loyihalash kerakligini, qanday sinflarga ega bo'lishi kerakligini va ular bir-biri bilan qanday munosabatda bo'lishi kerakligini tushunishga imkon beradi. Uning asosiy maqsadi - talablarni yig'ish bosqichida aniqlangan funksionallikni amalga oshirish yo'nalishini aniqlash va tizim arxitekturasini eskiz qilish.

Keyinchalik yaratilgan dizayn modelidan farqli o'laroq, tahlil modeli ko'proq kontseptual model bo'lib, faqat ishlab chiquvchilarni amalga oshirish sinflariga yaqinlashtiradi. Ushbu modelda oldingi modelda yuzaga kelishi mumkin bo'lgan qarama-qarshiliklar bo'lmasligi kerak.

UML yordamida tahlil modelini ko'rsatish uchun "chegara sinfi", "ob'ekt", "nazorat" stereotiplari (xulq-atvor namunalari) bo'lgan sinf diagrammasi va batafsillashtirish uchun hamkorlik diagrammasi qo'llaniladi (4-rasm). "Chegara sinfi" stereotipi tashqi faollar bilan o'zaro ta'sir qiluvchi sinfni, "ob'ekt" stereotipi ma'lumotlar ombori bo'lgan sinflarni va "nazorat" stereotipi ob'ektlarga so'rovlarni boshqaradigan sinflarni tasvirlaydi.

Shakl 4. Hamkorlik diagrammasining namunasi

Xabarlarni raqamlash ularning tartibini ko'rsatadi, lekin diagrammaning maqsadi almashilgan xabarlar tartibini hisobga olish emas, balki sinflarning bir-biri bilan aloqalarini aniq ko'rsatishdir.

Agar biz o'zaro ta'sir qilish tartibiga e'tibor qaratadigan bo'lsak, unda yana bir vakillik 5-rasmda ko'rsatilgan ketma-ketlik diagrammasi (Sequence) bo'ladi. Bu diagramma sizga jarayonning ketma-ketligini vizual ravishda ko'rsatib, vaqt o'tishi bilan xabarlar almashinuvini ko'rish imkonini beradi. Rational Rose kabi model yaratish vositasidan foydalanganda, ushbu ikki turdagi diagrammalar bir-biridan avtomatik ravishda yaratilishi mumkin (masalan, Rational Rose haqida ko'proq o'qishingiz mumkin).

Guruch. 5 Ketma-ketlik diagrammasiga misol

Ikki diagrammaning qaysi birini birinchi bo'lib yaratish qarori individual ishlab chiquvchining afzalliklariga bog'liq. Ushbu diagrammalar bir xil jarayonning tasviri bo'lganligi sababli, ularning ikkalasi ham ob'ektlar orasidagi o'zaro ta'sirni aks ettirishga imkon beradi.

3. Dizayn

Tizimni yaratish jarayonining keyingi bosqichi dizayn bo'lib, uning davomida avval yaratilgan modellar asosida dizayn modeli yaratiladi. Ushbu model tizimning jismoniy amalga oshirilishini aks ettiradi va yaratilgan mahsulotni sinf va komponentlar darajasida tavsiflaydi. Tahlil modelidan farqli o'laroq, dizayn modeli amalga oshirish shartlariga, dasturlash tillari va ishlatiladigan komponentlarga aniq bog'liqdir. Tizim arxitekturasini eng aniq tushunish uchun ushbu model iloji boricha rasmiylashtirilishi va butun tizimni ishlab chiqish hayoti davomida yangilanib turishi kerak.

Dizayn modelini yaratish uchun UML diagrammalarining butun majmuasi qo'llaniladi: sinf diagrammasi (5-rasm), hamkorlik diagrammasi, o'zaro ta'sir diagrammasi, faoliyat diagrammasi.

6-rasm. Sinf diagrammasining namunasi

Bundan tashqari, ushbu ish jarayoni Joylashtirish diagrammasi asosida amalga oshiriladigan joylashtirish modelini yaratishi mumkin. Bu tarmoqdagi qurilmalarni taqsimlashni modellashtirish uchun mo'ljallangan eng oddiy diagramma turi. Displey uchun protsessor va qurilma piktogrammalarining faqat ikkita varianti va ular orasidagi ulanishlar ishlatiladi.

4. Amalga oshirish

Amalga oshirish jarayonining asosiy vazifasi komponentlar ko'rinishidagi tizimni yaratishdir - manba matnlar dasturlar, skriptlar, ikkilik fayllar, bajariladigan fayllar va boshqalar. Ushbu bosqichda loyihalash modelining elementlari qanday amalga oshirilishini tavsiflovchi amalga oshirish modeli yaratiladi, qaysi sinflar aniq komponentlarga kiritiladi. Ushbu model tanlangan dasturlash muhitida qabul qilingan tuzilish va modullashtirish mexanizmlariga muvofiq ushbu komponentlarni tashkil qilish usulini tavsiflaydi va komponentlar diagrammasi bilan ifodalanadi (7-rasm).

guruch. 7 Komponentlar diagrammasi misoli

5. Sinov

Sinov jarayonida amalga oshirish natijalari tekshiriladi. Bu jarayon uchun test namunasi yaratiladi, u test holatlari, test protseduralari, test komponentlaridan iborat, lekin UML diagrammasi tasviriga ega emas, shuning uchun biz bu haqda to'xtalmaymiz.

6. Xulosa

Bu erda faqat Ratsional metodologiyaning asosiy jarayonlari ko'rib chiqildi. RUP juda keng bo'lib, turli xil dasturiy ta'minot loyihalarini amalga oshirish bo'yicha tavsiyalarni o'z ichiga oladi, bir necha kishidan iborat dasturchilar guruhi tomonidan dasturlarni yaratishdan tortib, turli qit'alarda minglab odamlarni birlashtirgan tarqatilgan dasturiy ta'minot loyihalarigacha. Biroq, ularning katta farqlariga qaramay, UML yordamida yaratilgan modellardan foydalanish usullari bir xil bo'ladi. Rivojlanishning turli bosqichlarida yaratilgan UML diagrammalari dasturiy ta'minot loyihasining qolgan artefaktlaridan ajralmas va ko'pincha individual RUP jarayonlari o'rtasidagi bog'liqlikdir.

Muayyan diagrammalardan foydalanish to'g'risidagi qaror kompaniyada tashkil etilgan rivojlanish jarayoniga bog'liq bo'lib, u birlashtirilgan deb ataladigan bo'lsa-da, muzlatilgan narsa emas. Rational nafaqat uni takomillashtirish va takomillashtirishni taklif qiladi, balki RUP ma'lumotlar bazasiga o'zgartirishlar kiritish uchun maxsus vositalarni ham taqdim etadi.

Ammo har qanday holatda ham, UML dan birlashtirilgan jarayon bilan birgalikda foydalanish prognoz qilinadigan natijaga erishish, ajratilgan byudjetni qondirish, loyiha ishtirokchilarining ta'sirini va yaratilgan dasturiy mahsulot sifatini oshirish imkonini beradi.

Kratchen. F. Kirish Ratsional birlashtirilgan jarayon . Ed. 2-chi - M.: Uilyams nashriyoti, 2002. - 240 pp.: kasal.

Jacobson A., Buch G., Rambo J. Birlashtirilgan dasturiy ta'minotni ishlab chiqish jarayoni - Sankt-Peterburg: Peter, 2002. - 496 pp.: kasal.

Fowler M., Scott K. UML qisqacha. Ob'ektni modellashtirishning standart tilini qo'llash: Transl. ingliz tilidan – M.:Mir, 1999. – 191 b., kasal.

Bek. E. Ekstremal dasturlash. – Sankt-Peterburg: Pyotr, 2002. – 224 b.: kasal.

TrofimovS. CASE texnologiyalari: Amaliy ish Rational Rose-da.
Ed. 2-chi - M .: Binom-Press, 2002 - 288 b.

Ratsional birlashtirilgan jarayon (RUP) Rational Software tomonidan yaratilgan dasturiy ta'minotni ishlab chiqish metodologiyasi.

Prinsiplar: Asosiy xavflarni erta aniqlash va doimiy (loyiha tugaguniga qadar) bartaraf etish. Mijozlarning bajariladigan dasturga bo'lgan talablarini qondirishga e'tibor qaratish (pretsedentlar modelini tahlil qilish va qurish (foydalanish holatlari)). Ishlab chiqish jarayonida talablar, dizayn qarorlari va amalga oshirishdagi o'zgarishlarni kuting. Komponent arxitekturasi loyihaning boshida amalga oshirildi va sinovdan o'tkazildi. Loyihani (mahsulotni) ishlab chiqishning barcha bosqichlarida uzluksiz sifat kafolati.

Arxitektorlar asosiy rol o'ynaydigan yaqin jamoada loyiha ustida ishlash.

RUP foydalanadi takroriy rivojlanish modeli. Har bir iteratsiya oxirida (ideal 2 dan 6 haftagacha) loyiha jamoasi ushbu iteratsiya uchun rejalashtirilgan maqsadlarga erishishi, dizayn artefaktlarini yaratishi yoki takomillashtirishi va yakuniy mahsulotning oraliq, ammo funktsional versiyasini olishi kerak.

Mahsulotni ishlab chiqishning to'liq hayot aylanishi quyidagilardan iborat to'rt bosqich, ularning har biri bir yoki bir nechta iteratsiyani o'z ichiga oladi: dastlabki bosqich, aniqlashtirish bosqichi, loyihalash va amalga oshirish.

Ekstremal dasturlash (XP)

Ekstremal dasturlash(Extreme Programming, XP) - dasturiy ta'minotni ishlab chiqishning moslashuvchan metodologiyalaridan biri

12 ta asosiy texnika Ekstremal dasturlashni (ekstremal dasturlash kitobining birinchi nashriga ko'ra tushuntiriladi) to'rt guruhga birlashtirilishi mumkin:

Qisqa tsikl fikr-mulohaza: (Sinovga asoslangan ishlab chiqish, rejalashtirish o'yini, mijoz har doim u erda, juft dasturlash

Ommaviy jarayondan ko'ra uzluksiz: Doimiy integratsiya, refaktoring, tez-tez kichik relizlar

Tushunish hamma tomonidan taqsimlanadi: Oddiylik, tizim metaforasi, kod yoki tanlangan dizayn naqshlarining jamoaviy egaligi, kodlash standarti

Dasturchining ijtimoiy ta'minoti: 40 soat ish haftasi

Juftlik dasturlash bir xil kompyuterda ishlaydigan juft dasturchilar tomonidan yaratilgan barcha kodlarni o'z ichiga oladi. Kollektiv egalik har bir jamoa a'zosi barcha manba kodlari uchun javobgar ekanligini anglatadi. XP-dagi "mijoz" hisob-kitoblarni to'lovchi emas, balki tizimdan haqiqatda foydalanadigan shaxsdir.

Hujjatlar standartlari

Standartlar loyihalar o'rtasidagi muvofiqlikni ta'minlaydi. Standartlar muhandislar o'rtasida tushunishni yaxshilaydi. Standartlar muhandislar tomonidan to'siqlar to'plami sifatida emas, balki ular uchun foydali narsa sifatida qabul qilinishi kerak. Intizomli va hujjatlashtirilgan yondashuvni talab qiladigan aniq va o'lchanadigan maqsadlar odatda ishlab chiquvchilar uchun yaxshi motivatsiya bo'ladi.

SVVP- Reja loyihaning bosqichlarini qanday va qanday ketma-ketlikda sinovdan o'tkazish kerakligini belgilaydi. Tekshirish - bu ilovaning to'g'ri tuzilganligini tekshirish jarayoni. Tasdiqlash talab qilinadigan mahsulot yig'ilganligini tasdiqlaydi.

SQAP- Dasturiy ta'minot sifatini nazorat qilish rejasi

SCMP- Boshqaruv rejasi dasturiy ta'minot loyihasi

SRS- Dasturiy ta'minot talablari spetsifikatsiyasi

SDD- Dasturiy ta'minot dizayn hujjatlari

STD- Dasturiy ta'minotni sinovdan o'tkazish uchun hujjatlar

Hujjatlarning izchilligi va yaxlitligi.

Hujjatlarni boshqarish muhim tashkiliy ko'nikmalarni talab qiladi. Yaxshi va moslashuvchan hujjatlarni yozish yaxshi va moslashuvchan kod yozishga o'xshaydi.

Hujjatlarni boshqarish uni saqlashni anglatadi to'liqlik Va mustahkamlik va shuningdek, o'z ichiga oladi konfiguratsiyani boshqarish.

To'liqlik - ishlab chiqish va texnik xizmat ko'rsatish jarayonini qamrab oluvchi hujjatlar to'plamining mavjudligi.

Muvofiqlik hujjatlar to'plamida ichki qarama-qarshiliklar mavjud emasligini bildiradi.Muammo shundaki, bu to'plam katta bo'lsa, unda bir-birini istisno qiluvchi bayonotlar paydo bo'lishining oldini olish juda qiyin.

Konfiguratsiyani qo'llab-quvvatlash - bu hujjatlar va dastur kodining turli versiyalari va qismlarini muvofiqlashtirishdir.