ასაშენებელი ელემენტების კომპონენტის დიაგრამა. პროგრამული უზრუნველყოფის დიზაინი. პროგრამის მთავარი მენიუ

UML არის ზოგადი დანიშნულების გრაფიკული მოდელირების ენა პროგრამული სისტემების განვითარების დროს შექმნილი ყველა არტეფაქტის დაზუსტებისთვის, ვიზუალიზაციისთვის, დიზაინისა და დოკუმენტაციისთვის.

ბევრი კარგი წიგნია, რომელიც დეტალურად აღწერს UML-ს (ზოგჯერ კი ძალიან დეტალურად), მსურს ერთ ადგილას შევაგროვო ძირითადი ცნებები დიაგრამების, ერთეულებისა და მათ შორის კავშირების შესახებ, სწრაფი გახსენებისთვის, რაღაც მოტყუების ფურცლის მსგავსი.

ამ სტატიაში გამოყენებულია მასალები წიგნებიდან: ივანოვი D. Yu., Novikov F. A. ერთიანი მოდელირების ენა UMLდა ლეონენკოვი. UML გაკვეთილი.

ჯერ გადავწყვიტოთ რედაქტორი. Linux-ში ვცადე UML-ის სხვადასხვა რედაქტორები, ყველაზე მეტად UMLet მომეწონა, თუმცა ჯავაზეა დაწერილი, ძალიან სწრაფად მოძრაობს და შეიცავს ერთეულების შაბლონების უმეტესობას. ასევე არის ArgoUML, მრავალპლატფორმული UML რედაქტორი, ასევე დაწერილი ჯავაში, რომელიც ფუნქციურად მდიდარია, მაგრამ უფრო ანელებს.

გავჩერდი UMlet, დააინსტალირეთ ქვეშ Arch Linuxდა უბუნტუ:

# Arch Linux-ზე yaourt -S umlet # Ubuntu-ზე sudo apt-get install umlet

UML-ში ყველა ერთეული შეიძლება დაიყოს შემდეგ ტიპებად:

• სტრუქტურული;
• ქცევითი;
• დაჯგუფება;
• ანოტაციური;

UML-ში გამოყენებული ურთიერთობების ოთხი ძირითადი ტიპია:

Დამოკიდებულება- მიუთითებს, რომ დამოუკიდებელ ერთეულში ცვლილება გარკვეულწილად მოქმედებს დამოკიდებულ ერთეულზე. გრაფიკულად, დამოკიდებულების ურთიერთობა გამოსახულია წერტილოვანი ხაზის სახით, ისრით, რომელიც მიმართულია დამოკიდებული ერთეულიდან დამოუკიდებელზე.

ასოციაცია- ხდება, თუ ერთი ერთეული პირდაპირ არის დაკავშირებული მეორესთან (ან სხვებთან - ასოციაცია შეიძლება იყოს არა მხოლოდ ორობითი). გრაფიკულად, ასოციაცია გამოსახულია როგორც მყარი ხაზი სხვადასხვა დამატებებით, რომლებიც აკავშირებს დაკავშირებულ ერთეულებს.

განზოგადებაარის ურთიერთობა ორ სუბიექტს შორის, რომელთაგან ერთი მეორის განსაკუთრებული (სპეციალიზებული) შემთხვევაა. გრაფიკულად, განზოგადება გამოსახულია, როგორც ხაზი სამკუთხა, შეუვსებელი ისრით ბოლოში, მიმართული კონკრეტულიდან (ქვეკლასიდან) ზოგადისკენ (სუპერკლასი).

იმპლემენტაციები- განხორციელების ურთიერთობა მიუთითებს, რომ ერთი სუბიექტი მეორეს განხორციელებაა. გრაფიკულად, იმპლემენტაცია გამოსახულია წერტილოვანი ხაზით სამკუთხა, შეუვსებელი ისრით ბოლოში, რომელიც მიმართულია განმახორციელებელი ერთეულიდან განხორციელებულ ერთეულზე.

IN UML 2განსაზღვრული 13 დიაგრამების ტიპები. სტანდარტების მიხედვით, თითოეულ დიაგრამას უნდა ჰქონდეს ჩარჩო მართკუთხედით (ქვედა მარჯვენა კუთხე დახრილი) ზედა მარცხენა კუთხეში, რომელიც მიუთითებს დიაგრამის იდენტიფიკატორზე (ტეგზე) და სათაურზე.

დიაგრამები, რომლებიც ასახავს სისტემის სტრუქტურას:

• კომპონენტის დიაგრამა (ტეგი კომპონენტი);
• განლაგების დიაგრამა, ტეგი განლაგება);
• კლასის დიაგრამა (კლასის დიაგრამა, ტეგი კლასი);
• ობიექტის დიაგრამა (ტეგი ობიექტი);
• კომპოზიტური სტრუქტურის დიაგრამა, ტეგი კლასი);

სისტემის ქცევის გამოსახვის დიაგრამები:

• სინქრონიზაციის დიაგრამა (ურთიერთქმედების დიაგრამა, ტეგი დროის განაწილება);
• აქტივობის დიაგრამა (ტეგი აქტივობა);
• თანმიმდევრობის დიაგრამა, ტეგი SD);
• კომუნიკაციის დიაგრამა (ტეგ კომ);
• სახელმწიფო მანქანის დიაგრამა, ტეგი სახელმწიფო მანქანა);
• ურთიერთქმედების მიმოხილვის დიაგრამა, ტეგი ურთიერთქმედება);

დიაგრამები გამოირჩევა:

• გამოიყენე ქეისის დიაგრამა (გამოყენების ქეისის დიაგრამა, გამოიყენე ქეისის ტეგი);
• პაკეტის დიაგრამა (პაკეტის დიაგრამა, ტეგი პაკეტი);

გამოყენების დიაგრამა

გამოყენების დიაგრამა(გამოყენების შემთხვევების დიაგრამა) არის სისტემის ფუნქციური დანიშნულების ყველაზე ზოგადი წარმოდგენა.

როდესაც განიხილავთ გამოყენების შემთხვევაში დიაგრამას, როგორც სისტემის მოდელს, შეგიძლიათ დაუკავშიროთ ის შავი ყუთის მოდელს. თითოეული გამოყენების შემთხვევა განსაზღვრავს მოქმედებების თანმიმდევრობას, რომელიც უნდა შეასრულოს შემუშავებულმა სისტემამ, როდესაც ის ურთიერთქმედებს შესაბამის აქტორთან.

გამოყენების დიაგრამა იყენებს ორი ტიპის ძირითად ერთეულს: გამოყენების შემთხვევები და აქტორები, რომელთა შორის დამყარებულია შემდეგი ძირითადი ტიპის ურთიერთობები.

ასოციაციის ურთიერთობა- ეს ურთიერთობა აკონკრეტებს, თუ რა კონკრეტულ როლს ასრულებს მსახიობი გამოყენების შემთხვევის მაგალითთან ურთიერთობისას. ასოციაციურ ურთიერთობაზე მითითებულია მყარი ხაზი მსახიობსა და გამოყენების შემთხვევას შორის. ამ ხაზს შეიძლება ჰქონდეს დამატებითი სიმბოლოები, როგორიცაა სახელი და სიმრავლე.

გაფართოების კავშირი- განსაზღვრავს ურთიერთობას კონკრეტული გამოყენების შემთხვევისა და უფრო ზოგადი გამოყენების შემთხვევებს შორის, რომელთა თვისებები განისაზღვრება ამ ინსტანციების ერთად გაერთიანების მეთოდის საფუძველზე. ამგვარად, თუ არსებობს A გამოყენების შემთხვევიდან B-ს გამოყენების გაფართოების კავშირი, მაშინ ეს ნიშნავს, რომ გამოყენების შემთხვევის B-ის თვისებები შეიძლება გაფართოვდეს გაფართოებული გამოყენების შემთხვევაში A-ში თვისებების არსებობის გამო.

გამოყენების შემთხვევებს შორის გაფართოების კავშირი მითითებულია წერტილოვანი ხაზით ისრით (დამოკიდებულების ურთიერთობის ვარიანტი), რომელიც მიუთითებს გამოყენების შემთხვევისგან, რომელიც არის ორიგინალური გამოყენების შემთხვევის გაფართოება.

განზოგადების მიმართებაემსახურება იმის მითითებას, რომ ზოგიერთი გამოყენების შემთხვევა A შეიძლება განზოგადდეს B შემთხვევისთვის. ამ შემთხვევაში, ვარიანტი A იქნება B ვარიანტის სპეციალიზაცია. ამ შემთხვევაში, B ეწოდება A-ს წინაპარს ან მშობელს, ხოლო ვარიანტი A არის. ვარიანტის გამოყენების შვილი V.

გრაფიკულად, ეს ურთიერთობა წარმოდგენილია მყარი ხაზით ისრით ღია სამკუთხედის სახით, რომელიც მიუთითებს მშობლის გამოყენების შემთხვევაზე.

გამოყენების შემთხვევებს შორის განზოგადების კავშირი გამოიყენება, როდესაც აუცილებელია აღინიშნოს, რომ ბავშვის გამოყენების შემთხვევებს აქვთ მშობლის გამოყენების შემთხვევების ყველა ატრიბუტი და ქცევა.

ინკლუზიური ურთიერთობაგამოყენების ორ შემთხვევას შორის მიუთითებს, რომ ერთი გამოყენების შემთხვევისთვის განსაზღვრული ქცევა შედის, როგორც შემადგენელი კომპონენტი მეორე გამოყენების შემთხვევის ქცევების თანმიმდევრობაში.

ჩართვის კავშირი, რომელიც მიმართულია გამოყენების შემთხვევიდან A-დან B შემთხვევამდე, მიუთითებს, რომ A გამოყენების შემთხვევის თითოეული შემთხვევა მოიცავს B გამოყენების შემთხვევისთვის მითითებულ ფუნქციურ თვისებებს.

გრაფიკულად, ეს ურთიერთობა მითითებულია წერტილოვანი ხაზით ისრით (დამოკიდებულების ურთიერთობის ვარიანტი), რომელიც მიმართულია საბაზისო გამოყენების შემთხვევიდან ჩართულზე.

კლასის დიაგრამა

კლასის დიაგრამა(კლასის დიაგრამა) არის სისტემის სტატიკური სტრუქტურის აღწერის მთავარი გზა.

კლასის დიაგრამა იყენებს ერთ ძირითად ტიპს: კლასებს (კლასების მრავალი განსაკუთრებული შემთხვევის ჩათვლით: ინტერფეისები, პრიმიტიული ტიპები, ასოციაციის კლასები და ა.

დამოკიდებულების ურთიერთობაზოგადად, მიუთითებს რაიმე სემანტიკურ ურთიერთობაზე მოდელის ორ ელემენტს ან ამ ელემენტების ორ კომპლექტს შორის, რომელიც არ არის ასოციაციის, განზოგადების ან განხორციელების მიმართება. დამოკიდებულების ურთიერთობა გამოიყენება იმ სიტუაციაში, როდესაც გარკვეული ცვლილება მოდელის ერთ ელემენტზე შეიძლება მოითხოვოს ცვლილება სხვა მოდელის ელემენტზე, რომელიც დამოკიდებულია მასზე.

დამოკიდებულების ურთიერთობა გრაფიკულად წარმოდგენილია წერტილოვანი ხაზით შესაბამის ელემენტებს შორის ისრით ერთ ბოლოში, ისარი მიმართულია დამოკიდებულების კლიენტის კლასიდან დამოუკიდებელ ან წყაროს კლასზე.

ისრის ზემოთ შეიძლება იყოს სპეციალური საკვანძო სიტყვები (სტერეოტიპები):

• "წვდომა" - ემსახურება კლიენტის კლასებისთვის წყაროს კლასის საჯარო ატრიბუტებისა და ოპერაციების ხელმისაწვდომობის მითითებას;
• "bind" - კლიენტის კლასს შეუძლია გამოიყენოს რაიმე შაბლონი მისი შემდგომი პარამეტრიზაციისთვის;
• "წარმოება" - კლიენტის კლასის ატრიბუტები შეიძლება გამოითვალოს წყაროს კლასის ატრიბუტებიდან;
• "იმპორტი" - წყარო კლასის საჯარო ატრიბუტები და ოპერაციები ხდება კლიენტის კლასის ნაწილი, თითქოს ისინი პირდაპირ მასშია გამოცხადებული;
• "დახვეწა" - მიუთითებს, რომ კლიენტის კლასი ემსახურება როგორც წყაროს კლასის დახვეწას ისტორიული მიზეზების გამო, როდესაც დამატებითი ინფორმაცია ჩნდება პროექტზე მუშაობის დროს.

ასოციაციის ურთიერთობაშეესაბამება კლასებს შორის გარკვეული ურთიერთობის არსებობას. ეს ურთიერთობა მითითებულია მყარი ხაზით დამატებითი სპეციალური სიმბოლოებით, რომლებიც ახასიათებს კონკრეტული ასოციაციის ინდივიდუალურ თვისებებს. დამატებითი სპეციალური სიმბოლოები შეიძლება იყოს ასოციაციის სახელი, ასევე ასოციაციის როლური კლასების სახელები და სიმრავლე. ასოციაციის სახელწოდება არის მისი აღნიშვნის არჩევითი ელემენტი.

აგრეგაციის მიმართებახდება რამდენიმე კლასს შორის, თუ რომელიმე კლასი წარმოადგენს ერთეულს, რომელიც მოიცავს სხვა ერთეულებს კომპონენტებად. იგი გამოიყენება "ნაწილი-მთელი" ტიპის სისტემური ურთიერთობების წარმოსაჩენად.

შემადგენლობის თანაფარდობაარის აგრეგაციის ურთიერთობის განსაკუთრებული შემთხვევა. ეს მიმართება ემსახურება „ნაწილი-მთელი“ მიმართების განსაკუთრებული ფორმის ხაზგასმას, რომელშიც შემადგენელი ნაწილები გარკვეულწილად განლაგებულია მთლიანში. მათ შორის ურთიერთობის სპეციფიკა მდგომარეობს იმაში, რომ ნაწილებს არ შეუძლიათ იმოქმედონ მთლიანისგან იზოლირებულად, ანუ მთლიანის განადგურებით ნადგურდება მისი ყველა შემადგენელი ნაწილი.

განზოგადების მიმართებაარის ურთიერთობა უფრო ზოგად ელემენტს (მშობელი ან წინაპარი) და უფრო სპეციფიკურ ან სპეციალიზებულ ელემენტს (შვილი ან შთამომავალი) შორის. როდესაც გამოიყენება კლასის დიაგრამაზე, ეს ურთიერთობა აღწერს კლასების იერარქიულ სტრუქტურას და მათი თვისებების და ქცევის მემკვიდრეობას. ეს ვარაუდობს, რომ შთამომავლობის კლასს აქვს წინაპართა კლასის ყველა თვისება და ქცევა, ასევე აქვს თავისი თვისებები და ქცევა, რაც წინაპართა კლასს არ გააჩნია.

მანქანის დიაგრამა

მანქანის დიაგრამა(სახელმწიფო მანქანის დიაგრამა) ან მდგომარეობის დიაგრამა UML 1-ში (მდგომარეობების დიაგრამა) არის UML-ში ქცევის დეტალურად აღწერის ერთ-ერთი გზა. არსებითად, მანქანების დიაგრამები, როგორც სახელიდან ჩანს, არის სასრული მდგომარეობის მანქანის მდგომარეობისა და გადასვლების გრაფიკი, რომელიც დატვირთულია მრავალი დამატებითი დეტალებითა და დეტალებით.

მდგომარეობის დიაგრამა აღწერს მხოლოდ ერთი კლასის, უფრო ზუსტად, გარკვეული კლასის ერთი ინსტანციის მდგომარეობების შეცვლის პროცესს, ანუ აყალიბებს კონკრეტული ობიექტის მდგომარეობის ყველა შესაძლო ცვლილებას. ამ შემთხვევაში, ობიექტის მდგომარეობის ცვლილება შეიძლება გამოწვეული იყოს გარე ზემოქმედებით სხვა ობიექტებიდან ან გარედან. ამგვარ გარე ზემოქმედებაზე ობიექტის რეაქციის აღსაწერად გამოიყენება მდგომარეობის დიაგრამები.

ავტომატურ დიაგრამაში გამოიყენება ერთეულის ერთი ძირითადი ტიპი - მდგომარეობები და ურთიერთობის ერთი ტიპი - გადასვლები, მაგრამ ორივესთვის განისაზღვრება მრავალი სახეობა, სპეციალური შემთხვევები და დამატებითი აღნიშვნები. ავტომატი ასახავს მოდელირებული სისტემის დინამიურ ასპექტებს მიმართული გრაფიკის სახით, რომლის წვეროები შეესაბამება მდგომარეობებს, ხოლო რკალი – გადასვლებს.

საწყისი მდგომარეობაარის სახელმწიფოს განსაკუთრებული შემთხვევა, რომელიც არ შეიცავს რაიმე შინაგან მოქმედებებს (ფსევდოსახელმწიფო). ობიექტი საწყის დროს ნაგულისხმევად ამ მდგომარეობაშია. ის ემსახურება მდგომარეობის დიაგრამაზე გრაფიკული არეალის მითითებას, საიდანაც იწყება მდგომარეობის შეცვლის პროცესი.

ფინალი (ფინალი)სახელმწიფო არის სახელმწიფოს განსაკუთრებული შემთხვევა, რომელიც ასევე არ შეიცავს რაიმე შინაგან მოქმედებებს (ფსევდოსახელმწიფოები). ობიექტი ნაგულისხმევად იქნება ამ მდგომარეობაში მას შემდეგ, რაც მანქანა დაასრულებს მუშაობას დროის ბოლო მომენტში.

აქტივობის დიაგრამა

შემუშავებული ან გაანალიზებული სისტემის ქცევის მოდელირებისას საჭირო ხდება არა მხოლოდ მისი მდგომარეობის შეცვლის პროცესის წარმოდგენა, არამედ სისტემის მიერ შესრულებული ოპერაციების ალგორითმული და ლოგიკური განხორციელების მახასიათებლების დეტალურად დაწვა.

აქტივობის დიაგრამა(აქტივობის დიაგრამა) არის ქცევის აღწერის კიდევ ერთი გზა, რომელიც ვიზუალურად წააგავს ალგორითმის ძველ კარგ დიაგრამას. გამოიყენება ოპერაციების შესრულების პროცესის მოდელირებისთვის.

აქტივობების დიაგრამების ძირითადი გამოყენებაა კლასის ოპერაციების განხორციელების მახასიათებლების ვიზუალიზაცია, როდესაც საჭიროა მათი განხორციელების ალგორითმების წარმოდგენა.

აქტივობის დიაგრამა იყენებს ერთეულების ერთ ძირითად ტიპს - მოქმედებას და ურთიერთობის ერთ ტიპს - გადასვლებს (კონტროლის გადაცემას). ასევე გამოიყენება კონსტრუქციები, როგორიცაა ჩანგლები, შერწყმა, კავშირები და განშტოებები. მარტივი მოქმედების სახელად რეკომენდებულია ზმნის გამოყენება განმარტებითი სიტყვებით.

თანმიმდევრობის დიაგრამა

თანმიმდევრობის დიაგრამა(მიმდევრობის დიაგრამა) არის სისტემის ქცევის „მაგალითების გამოყენებით“ აღწერის საშუალება.

სინამდვილეში, მიმდევრობის დიაგრამა არის სისტემის კონკრეტული სესიის პროტოკოლის ჩანაწერი (ან ასეთი პროტოკოლის ფრაგმენტი). ობიექტზე ორიენტირებულ პროგრამირებაში, მუშაობის დროს ყველაზე მნიშვნელოვანი არის შეტყობინებების გადაცემა საკომუნიკაციო ობიექტებს შორის. ეს არის შეტყობინების გაგზავნის თანმიმდევრობა, რომელიც ნაჩვენებია ამ დიაგრამაში, აქედან გამომდინარეობს სახელი.

მიმდევრობის დიაგრამა იყენებს ერთეულების ერთ ძირითად ტიპს - ურთიერთქმედების კლასიფიკატორების (ძირითადად კლასების, კომპონენტების და აქტორების) შემთხვევებს და ურთიერთობის ერთ ტიპს - ბმულებს, რომლებზეც ხდება შეტყობინებების გაცვლა.

შეტყობინებების შესაძლო ტიპები (სურათი აღებულია larin.in-დან):

კომუნიკაციის დიაგრამა

კომუნიკაციის დიაგრამა(კომუნიკაციის დიაგრამა) - ქცევის აღწერის ხერხი, რომელიც სემანტიკურად ექვივალენტურია მიმდევრობის დიაგრამასთან. სინამდვილეში, ეს არის კლასიფიკატორების ურთიერთქმედების ინსტანციების შეტყობინებების გაცვლის თანმიმდევრობის იგივე აღწერა, რომელიც გამოხატულია მხოლოდ სხვა გრაფიკული საშუალებებით.

ამრიგად, საკომუნიკაციო დიაგრამაში, ისევე როგორც თანმიმდევრობის დიაგრამაში, გამოიყენება ერთეულის ერთი ძირითადი ტიპი - ურთიერთქმედების კლასიფიკატორების შემთხვევები და ურთიერთობის ერთი ტიპი - კავშირები. თუმცა აქ აქცენტი კეთდება არა დროზე, არამედ კონკრეტულ ინსტანციებს შორის კავშირების სტრუქტურაზე.

კომპონენტის დიაგრამა

კომპონენტის დიაგრამა(კომპონენტური დიაგრამა) - გვიჩვენებს ურთიერთობებს მოდულებს შორის (ლოგიკური თუ ფიზიკური), რომლებიც ქმნიან მოდელირებულ სისტემას.

კომპონენტის დიაგრამაში ერთეულების ძირითადი ტიპია თავად კომპონენტები, ისევე როგორც ინტერფეისები, რომლებითაც განისაზღვრება კომპონენტებს შორის ურთიერთობა. კომპონენტების დიაგრამაში გამოიყენება შემდეგი ურთიერთობები:

• დანერგვები კომპონენტებსა და ინტერფეისებს შორის (კომპონენტი ახორციელებს ინტერფეისს);
• დამოკიდებულებები კომპონენტებსა და ინტერფეისებს შორის (კომპონენტი იყენებს ინტერფეისს);

განლაგების დიაგრამა

განლაგების დიაგრამა(განლაგების დიაგრამა), სისტემის ელემენტების შემადგენლობისა და კავშირების ჩვენებასთან ერთად, აჩვენებს, თუ როგორ არიან ისინი ფიზიკურად განლაგებული გამოთვლით რესურსებზე მუშაობის დროს.

განლაგების დიაგრამა, კომპონენტურ დიაგრამასთან შედარებით, ამატებს ორი ტიპის ერთეულს: არტეფაქტს, რომელიც წარმოადგენს კომპონენტისა და კვანძის იმპლემენტაციას (შეიძლება იყოს კლასიფიკატორი, რომელიც აღწერს კვანძის ტიპს ან კონკრეტულ მაგალითს) და ასოციაციის ურთიერთობა. კვანძებს შორის, რაც მიუთითებს, რომ კვანძები ფიზიკურად დაკავშირებულია შესრულების დროს.

ობიექტის დიაგრამა

ობიექტის დიაგრამა(ობიექტის დიაგრამა) - არის კლასის დიაგრამის მაგალითი.

ობიექტის დიაგრამა იყენებს ერთეულების ერთ ძირითად ტიპს: ობიექტებს (კლასების ინსტანციები), რომელთა შორის მითითებულია კონკრეტული კავშირები (ყველაზე ხშირად ასოციაციების შემთხვევები). ობიექტების დიაგრამები დამხმარე ხასიათს ატარებს - სინამდვილეში, ეს არის მაგალითები (მეხსიერების ნაგავსაყრელები, შეიძლება ითქვას), აჩვენებს რა ობიექტებია ხელმისაწვდომი და მათ შორის კავშირები სისტემის მუშაობის გარკვეულ მომენტში.

შიდა სტრუქტურის დიაგრამა(კომპოზიტური სტრუქტურის დიაგრამა) გამოიყენება სტრუქტურული კლასიფიკატორების, ძირითადად კლასებისა და კომპონენტების უფრო დეტალური წარმოდგენისთვის.

სტრუქტურული კლასიფიკატორი გამოსახულია მართკუთხედის სახით, კლასიფიკატორის სახელით ზემოთ. შიგნით არის ნაწილები. შეიძლება რამდენიმე ნაწილი იყოს. ნაწილებს შეუძლიათ ურთიერთქმედება ერთმანეთთან. ეს მითითებულია სხვადასხვა ტიპის კონექტორების გამოყენებით. იმ ნაწილის გარე საზღვარზე ადგილს, რომელსაც კონექტორი ერთვის, ეწოდება პორტი. პორტები ასევე განლაგებულია სტრუქტურული კლასიფიკატორის გარე საზღვარზე.

ურთიერთქმედების მიმოხილვის დიაგრამაურთიერთქმედების მიმოხილვის დიაგრამა არის აქტივობის დიაგრამის ტიპი გაფართოებული სინტაქსით: ურთიერთქმედების მიმოხილვის დიაგრამის ელემენტები შეიძლება იყოს ბმულები ურთიერთქმედების გამოყენებასთან, რომლებიც განსაზღვრულია თანმიმდევრული დიაგრამებით.

დროის დიაგრამა

დროის დიაგრამადროის დიაგრამა არის მიმდევრობის დიაგრამის სპეციალური ფორმა, რომელიც ფოკუსირებულია სხვადასხვა კლასიფიკატორის ინსტანციების ცვალებად მდგომარეობებზე და მათი დროის სინქრონიზაციაზე.

პაკეტის დიაგრამა

პაკეტის დიაგრამა(პაკეტის დიაგრამა) ერთადერთი ინსტრუმენტია, რომელიც საშუალებას გაძლევთ მართოთ თავად მოდელის სირთულე.

ნოტაციის ძირითადი ელემენტებია პაკეტები და დამოკიდებულებები სხვადასხვა სტერეოტიპებით.

ერთეულთან ურთიერთობის მოდელი (ER მოდელი)

ანალოგი კლასის დიაგრამები(UML) შესაძლოა ER მოდელი, რომელიც გამოიყენება მონაცემთა ბაზების შემუშავებისას (რელაციური მოდელი).

ერთეულთან ურთიერთობის მოდელი (ER-model) არის მონაცემთა მოდელი, რომელიც საშუალებას გაძლევთ აღწეროთ საგნის არეალის კონცეპტუალური დიაგრამები. ER მოდელი გამოიყენება მაღალი დონის (კონცეპტუალური) მონაცემთა ბაზის დიზაინში. მისი დახმარებით თქვენ შეგიძლიათ ამოიცნოთ ძირითადი ერთეულები და დაადგინოთ კავშირები, რომლებიც შეიძლება დამყარდეს ამ ერთეულებს შორის. ვიკიპედია

საგნის არეალის ნებისმიერი ფრაგმენტი შეიძლება წარმოდგენილი იყოს როგორც ერთეულების ერთობლიობა, რომელთა შორის არის რამდენიმე კავშირი.

Ძირითადი ცნებები:

არსი(ერთეული) არის ობიექტი, რომლის იდენტიფიცირება შესაძლებელია ისე, რომ განასხვავოს იგი სხვა ობიექტებისგან, მაგალითად, კლიენტი 777. ერთეული რეალურად არის ატრიბუტების ნაკრები.

ერთეული კომპლექტი(ერთეული კომპლექტი) - ერთი და იგივე ტიპის ერთეულების ერთობლიობა (ერთნაირი თვისებების მქონე).

კავშირი(ურთიერთობა) არის რამდენიმე სუბიექტს შორის დამყარებული ასოციაცია.

დომენი(დომენი) - ატრიბუტის მნიშვნელობების ნაკრები (განმარტების დომენი).

არსებობს სამი სახის ბინარული ობლიგაციები:

• ერთი ერთი- ერთი კლასის ერთეულის ერთი ეგზემპლარი ასოცირდება სხვა კლასის ერთეულის ერთ ეგზემპლართან, მაგალითად, HEAD - DEPARTMENT;
• 1-მდე ნან ერთი ბევრს- ერთი კლასის ერთეულის ერთი ეგზემპლარი ასოცირდება სხვა კლასის სუბიექტის ბევრ ეგზემპლართან, მაგალითად, DEPARTMENT - EMPLOYEE;
• N-მდე Mან ბევრი ბევრს- ერთი კლასის სუბიექტის მრავალი შემთხვევა ასოცირდება სხვა კლასის სუბიექტის ბევრ შემთხვევასთან, მაგალითად, EMPLOYEE - PROJECT;
ძირითადი ცნებების ლექსიკონი UML-ში

ობიექტი- ერთეული, რომელიც უნიკალურია და მოიცავს მდგომარეობას და ქცევას.

Კლასი- ობიექტების ერთობლიობის აღწერა საერთო ატრიბუტებით, რომლებიც განსაზღვრავენ მდგომარეობას და მოქმედებებს, რომლებიც განსაზღვრავენ ქცევას.

ინტერფეისი- ოპერაციების დასახელებული ნაკრები, რომელიც განსაზღვრავს სერვისების ერთობლიობას, რომელიც შეიძლება მოითხოვოს მომხმარებელმა და უზრუნველყოს მომსახურების მიმწოდებელი.

თანამშრომლობა- ობიექტების ნაკრები, რომლებიც ურთიერთქმედებენ გარკვეული მიზნის მისაღწევად.

Მსახიობი- ერთეული, რომელიც მდებარეობს მოდელირებული სისტემის გარეთ და უშუალოდ ურთიერთქმედებს მასთან.

Კომპონენტი- სისტემის მოდულარული ნაწილი საჭირო და მოწოდებული ინტერფეისების მკაფიოდ განსაზღვრული ნაკრებით.

არტეფაქტი- ინფორმაციის ელემენტი, რომელიც გამოიყენება ან გენერირდება პროგრამული უზრუნველყოფის განვითარების პროცესში. სხვა სიტყვებით რომ ვთქვათ, არტეფაქტი არის განხორციელების ფიზიკური ერთეული, რომელიც მიღებულია მოდელის ელემენტიდან (როგორიცაა კლასი ან კომპონენტი).

კვანძი- გამოთვლითი რესურსი, რომელზედაც განთავსებულია არტეფაქტები და, საჭიროების შემთხვევაში, შესრულებულია.

ქცევითი ერთეულები გამიზნულია ქცევის აღსაწერად. არსებობს მხოლოდ ორი ძირითადი ქცევითი ერთეული: მდგომარეობა და მოქმედება.

სახელმწიფო- ობიექტის სასიცოცხლო ციკლის პერიოდი, რომლის დროსაც ობიექტი აკმაყოფილებს გარკვეულ მდგომარეობას და ახორციელებს საკუთარ საქმიანობას ან ელოდება რაიმე მოვლენის დადგომას.

მოქმედება- პრიმიტიული ატომური გაანგარიშება.

მანქანაარის პაკეტი, რომელიც განსაზღვრავს ბევრ კონცეფციას, რომელიც აუცილებელია მოდელირებული ერთეულის ქცევის წარმოსადგენად დისკრეტული სივრცის სახით, სასრული რაოდენობის მდგომარეობებითა და გადასვლებით.

კლასიფიკატორიარის იმავე ტიპის ობიექტების სიმრავლის აღმწერი.

დამატებითი კითხვა

• Fowler M. UML. საფუძვლები, მე-3 გამოცემა
• Buch G., Rambo D., Jacobson I. UML ენა. Მომხმარებლის სახელმძღვანელო

ამ ტიპის დიაგრამა მიზნად ისახავს კლასების და ობიექტების კატეგორიზაციას სისტემის ფიზიკურ დიზაინში კომპონენტებს შორის. ამ ტიპის დიაგრამას ხშირად უწოდებენ მოდულის დიაგრამებს.

კომპონენტის დიაგრამა, განსხვავებით ადრე განხილული დიაგრამებისგან, აღწერს სისტემის ფიზიკური წარმოდგენის მახასიათებლებს. კომპონენტის დიაგრამა საშუალებას გაძლევთ განსაზღვროთ შემუშავებული სისტემის არქიტექტურა პროგრამული უზრუნველყოფის კომპონენტებს შორის დამოკიდებულების დადგენით, რაც შეიძლება იყოს წყარო, ორობითი და შესრულებადი კოდი. განვითარების ბევრ გარემოში, მოდული ან კომპონენტი შეესაბამება ფაილს. მოდულების დამაკავშირებელი წერტილოვანი ისრები აჩვენებს ურთიერთდამოკიდებულების მსგავს კავშირებს, რაც ხდება პროგრამის საწყისი კოდის შედგენისას. კომპონენტის დიაგრამის ძირითადი გრაფიკული ელემენტებია კომპონენტები, ინტერფეისები და მათ შორის დამოკიდებულებები.

Კომპონენტი(კომპონენტი) - სისტემის ფიზიკურად არსებული ნაწილი, რომელიც უზრუნველყოფს კლასებისა და ურთიერთობების განხორციელებას, ასევე მოდელირებული პროგრამული სისტემის ფუნქციონალურ ქცევას.

კომპონენტების უფრო ვიზუალური წარმოდგენისთვის შემოთავაზებული იქნა შემდეგი გრაფიკული სტერეოტიპები და გახდა ზოგადად მიღებული:

პირველი, სტერეოტიპები განლაგების კომპონენტებისთვის, რომლებიც პირდაპირ აძლევს სისტემას მისი ფუნქციების შესრულების საშუალებას. ასეთი კომპონენტები შეიძლება იყოს დინამიურად დაკავშირებული ბიბლიოთეკები (ნახ. 12, ა), ვებ გვერდები ჰიპერტექსტის მარკირების ენაზე (ნახ. 12, ბ) და დამხმარე ფაილები (ნახ. 12, გ).

მეორე, სტერეოტიპები კომპონენტებისთვის სამუშაო პროდუქტების სახით. როგორც წესი, ეს არის ფაილები პროგრამების წყაროს კოდებით (ნახ. 12, დ).

ბრინჯი. 12.კომპონენტების გრაფიკული წარმოდგენის ვარიანტები კომპონენტის დიაგრამაზე.

ამ ელემენტებს ზოგჯერ უწოდებენ არტეფაქტებიხაზს უსვამს მათ სრულ საინფორმაციო შინაარსს, შესაბამისი კომპონენტების განხორციელების სპეციფიკური ტექნოლოგიის მიხედვით. უფრო მეტიც, დეველოპერებს შეუძლიათ გამოიყენონ საკუთარი აღნიშვნა ამ მიზნით, რადგან UML ენას არ აქვს მკაცრი აღნიშვნა არტეფაქტების გრაფიკული წარმოდგენისთვის.

სხვადასხვა სახის კომპონენტების მითითების კიდევ ერთი გზაა კომპონენტის ტექსტური სტერეოტიპის მითითება მისი სახელის წინ. UML განსაზღვრავს შემდეგ სტერეოტიპებს კომპონენტებისთვის:

<> (ფაილი) – განსაზღვრავს კომპონენტის ყველაზე გავრცელებულ ტიპს, რომელიც წარმოდგენილია როგორც თვითნებური ფიზიკური ფაილი.

<> (შესასრულებელი) – განსაზღვრავს ფაილის კომპონენტის ტიპს, რომელიც არის შესრულებადი ფაილი და შეიძლება შესრულდეს კომპიუტერულ პლატფორმაზე.

<> (დოკუმენტი) – განსაზღვრავს ფაილის კომპონენტის ტიპს, რომელიც წარმოდგენილია თვითნებური შინაარსის დოკუმენტის სახით, რომელიც არ არის შესრულებადი ფაილი ან ფაილი პროგრამის საწყისი კოდით.

<> (ბიბლიოთეკა) – განსაზღვრავს ფაილის კომპონენტის ტიპს, რომელიც წარმოდგენილია დინამიური ან სტატიკური ბიბლიოთეკის სახით.

<> (წყარო) – განსაზღვრავს ფაილის კომპონენტის ტიპს, რომელიც არის ფაილი პროგრამის საწყისი ტექსტით, რომელიც კომპილაციის შემდეგ შეიძლება გარდაიქმნას შესრულებად ფაილად.

<

> (ცხრილი) – განსაზღვრავს კომპონენტის ტიპს, რომელიც წარმოდგენილია მონაცემთა ბაზის ცხრილის სახით.

ინტერფეისები

ინტერფეისსა და კომპონენტს შორის კომუნიკაციის ორი გზა არსებობს. თუ კომპონენტი ახორციელებს რაიმე ინტერფეისს, მაშინ ასეთ ინტერფეისს ეწოდება ექსპორტირებული ან მხარი დაუჭირა, რადგან ეს კომპონენტი მას სხვა კომპონენტებს ემსახურება. თუ კომპონენტი იყენებს ინტერფეისს, რომელიც დანერგილია სხვა კომპონენტის მიერ, მაშინ პირველი კომპონენტისთვის ასეთ ინტერფეისს იმპორტირებული ეწოდება. იმპორტირებული ინტერფეისის თავისებურება ის არის, რომ კომპონენტის დიაგრამაში ეს ურთიერთობა გამოსახულია დამოკიდებულების გამოყენებით.

კომპონენტის დიაგრამას ასევე შეუძლია წარმოადგინოს დამოკიდებულების ურთიერთობა კომპონენტებსა და მათ მიერ განხორციელებულ კლასებს შორის. ეს ინფორმაცია მნიშვნელოვანია სისტემის მოდელის ლოგიკურ და ფიზიკურ წარმოდგენებს შორის თანმიმდევრულობის უზრუნველსაყოფად. რა თქმა უნდა, კლასის განმარტებების სტრუქტურაში ცვლილებებმა შეიძლება შეცვალოს ეს დამოკიდებულება. ქვემოთ მოცემულია მსგავსი ტიპის დამოკიდებულების ფრაგმენტი, სადაც Control .exe შესრულებადი დამოკიდებულია შესაბამის კლასებზე.

ბრინჯი.კომპონენტსა და კლასებს შორის დამოკიდებულების გრაფიკული წარმოდგენა.

ამ შემთხვევაში, კომპონენტის დიაგრამა არ მიუთითებს, რომ კლასები განხორციელებულია კომპონენტის მიერ. თუ გსურთ ხაზგასმით აღვნიშნოთ, რომ კომპონენტი ახორციელებს ცალკეულ კლასებს, მაშინ გაფართოებული მართკუთხედის სიმბოლო გამოიყენება კომპონენტის აღსანიშნავად. ამ შემთხვევაში, კომპონენტის ოთხკუთხედი იყოფა ორ ნაწილად ჰორიზონტალური ხაზით. ზედა განყოფილება გამოიყენება კომპონენტის სახელის და, შესაძლოა, დამატებითი ინფორმაციის ჩასაწერად, ხოლო ქვედა სექცია გამოიყენება ამ კომპონენტის მიერ განხორციელებული კლასების მითითებისთვის.

სრული პროგრამული სისტემის დიზაინი არის ლოგიკური და ფიზიკური დონის მოდელების ნაკრები, რომლებიც უნდა შეესაბამებოდეს ერთმანეთს. UML იყენებს განხორციელების დიაგრამებს სისტემის მოდელების ფიზიკურად წარმოსადგენად, რომელიც მოიცავს კომპონენტის დიაგრამას და განლაგების დიაგრამას.

კომპონენტის დიაგრამა, განსხვავებით ადრე განხილული დიაგრამებისგან, აღწერს სისტემის ფიზიკური წარმოდგენის მახასიათებლებს. ის საშუალებას გაძლევთ განსაზღვროთ შემუშავებული სისტემის არქიტექტურა პროგრამული უზრუნველყოფის კომპონენტებს შორის დამოკიდებულების დადგენით, რაც შეიძლება იყოს წყარო და შესრულებადი კოდი. კომპონენტის დიაგრამის ძირითადი გრაფიკული ელემენტებია კომპონენტები, ინტერფეისები და მათ შორის დამოკიდებულებები.

კომპონენტის დიაგრამა შემუშავებულია შემდეგი მიზნებისთვის:

პროგრამული სისტემის საწყისი კოდის ზოგადი სტრუქტურის ვიზუალიზაცია;

პროგრამული სისტემის შესრულებადი ვერსიის სპეციფიკაციები;

ინდივიდუალური პროგრამის კოდის ფრაგმენტების ხელახალი გამოყენების უზრუნველყოფა;

კონცეპტუალური და ფიზიკური მონაცემთა ბაზის სქემების წარმოდგენები.

კომპონენტების დიაგრამების შემუშავებაში ჩართული არიან სისტემის ანალიტიკოსები და არქიტექტორები, ასევე პროგრამისტები. კომპონენტის დიაგრამა უზრუნველყოფს თანმიმდევრულ გადასვლას ლოგიკური წარმოდგენიდან პროექტის კონკრეტულ განხორციელებაზე პროგრამული კოდის სახით. ზოგიერთი კომპონენტი შეიძლება არსებობდეს მხოლოდ პროგრამის კოდის შედგენის ეტაპზე, ზოგი კი მისი შესრულების ეტაპზე. კომპონენტის დიაგრამა ასახავს ზოგად დამოკიდებულებებს კომპონენტებს შორის, განიხილავს ამ უკანასკნელს, როგორც კლასიფიკატორს.

კომპონენტები

UML ენაზე ფიზიკური პირების წარმოსაჩენად გამოიყენება სპეციალური ტერმინი - კომპონენტი. კომპონენტი ახორციელებს ინტერფეისების გარკვეულ კომპლექტს და ემსახურება ზოგადად მოდელის ფიზიკური წარმოდგენის ელემენტების განსაზღვრას. კომპონენტის გრაფიკულად წარმოსადგენად გამოიყენება სპეციალური სიმბოლო - მართკუთხედი მარცხნივ ჩასმული ორი პატარა ოთხკუთხედით. დიდი მართკუთხედის შიგნით არის კომპონენტის სახელი და, საჭიროების შემთხვევაში, დამატებითი ინფორმაცია. ამ სიმბოლოს გარეგნობა შეიძლება ოდნავ განსხვავდებოდეს კომპონენტთან დაკავშირებული ინფორმაციის ბუნების მიხედვით.

კომპონენტის სახელი მიჰყვება UML ენაზე მოდელის ელემენტების დასახელების ზოგად წესებს და შეიძლება შედგებოდეს ასოების, რიცხვებისა და ზოგიერთი სასვენი ნიშნისგან.

ინდივიდუალური კომპონენტი შეიძლება წარმოდგენილი იყოს ტიპის დონეზე ან ინსტანციის დონეზე. გრაფიკული გამოსახულება ორივე შემთხვევაში ერთნაირია, მაგრამ კომპონენტის სახელის ჩაწერის წესები განსხვავებულია. თუ კომპონენტი წარმოდგენილია ტიპის დონეზე, მაშინ მხოლოდ კაპიტალიზებული ტიპის სახელი იწერება მის სახელად. თუ კომპონენტი წარმოდგენილია ინსტანციის დონეზე, მაშინ იწერება მისი სახელი<имя компонента>":"<имя типаХ>. ამ შემთხვევაში, მთელი სახელის ხაზი ხაზგასმულია.

როგორც მარტივი სახელები, ჩვეულებრივ გამოიყენება შესრულებადი ფაილების სახელები (გამყოფი წერტილის შემდეგ exe გაფართოების მითითებით), დინამიური ბიბლიოთეკები (dll გაფართოება), ვებ გვერდები (html გაფართოება), ტექსტური ფაილები (txt ან doc გაფართოება) ან დახმარების ფაილები. (hip), მონაცემთა ბაზის ფაილები (DB) ან ფაილები პროგრამის წყაროს კოდებით (h, cpp გაფართოებები C++ ენისთვის, java გაფართოება Java ენისთვის), სკრიპტები (pi, asp) და სხვა.

ვინაიდან სისტემის მოდელის ლოგიკური წარმოდგენის სპეციფიკური განხორციელება დამოკიდებულია გამოყენებულ პროგრამულ ინსტრუმენტებზე, კომპონენტების სახელები განისაზღვრება შესაბამისი პროგრამირების ენის სინტაქსის მახასიათებლებით.

ზოგიერთ შემთხვევაში, ინფორმაცია თანდართული პაკეტის დასახელებისა და ამ კომპონენტის განხორციელების კონკრეტული ვერსიის შესახებ შეიძლება დაემატოს კომპონენტის მარტივ სახელს. ამ შემთხვევაში, ვერსიის ნომერი იწერება მონიშნული მნიშვნელობის სახით ხვეული ბრეკეტებში. სხვა შემთხვევებში, კომპონენტის სიმბოლო შეიძლება დაიყოს სექციებად, რათა მკაფიოდ მიუთითოს მის მიერ დანერგილი ინტერფეისების სახელები.

ვინაიდან კომპონენტი, როგორც მოდელის ფიზიკური განხორციელების ელემენტი, წარმოადგენს ცალკე კოდის მოდულს, ზოგჯერ მასზე კომენტირებულია დამატებითი გრაფიკული სიმბოლოები, რომლებიც ასახავს მისი განხორციელების სპეციფიკურ მახასიათებლებს. ეს დამატებითი ანოტაციები არ არის მითითებული UML-ში, მაგრამ მათი გამოყენება აადვილებს კომპონენტის დიაგრამის გაგებას ფიზიკური წარმოდგენის სიცხადის გაუმჯობესებით.

UML-ში სამი სახის კომპონენტია:

განლაგება, რომელიც საშუალებას აძლევს სისტემას უშუალოდ შეასრულოს თავისი ფუნქციები. ასეთი კომპონენტები შეიძლება იყოს დინამიური ბმული ბიბლიოთეკები dll გაფართოებით, ვებ გვერდები ჰიპერტექსტის მარკირების ენაზე html გაფართოებით და დახმარების ფაილები hlp გაფართოებით;

სამუშაო პროდუქტები. როგორც წესი, ეს არის ფაილები პროგრამების საწყისი კოდით, მაგალითად, h ან cpp გაფართოებებით C++ ენისთვის;

აღსრულებები, რომლებიც არის შესრულებადი მოდულები - ფაილები exe გაფართოებით.

ამ ელემენტებს ზოგჯერ უწოდებენ არტეფაქტებს, რაც ხაზს უსვამს მათ სრულ საინფორმაციო შინაარსს, რაც დამოკიდებულია შესაბამისი კომპონენტების განხორციელების სპეციფიკურ ტექნოლოგიაზე.

სხვადასხვა სახის კომპონენტების დაზუსტების კიდევ ერთი გზაა სახელის წინ მისი კომპონენტის სტერეოტიპის მკაფიოდ მითითება. UML განსაზღვრავს შემდეგ სტერეოტიპებს კომპონენტებისთვის:

ბიბლიოთეკა - განსაზღვრავს კომპონენტის პირველ ტიპს, რომელიც წარმოდგენილია დინამიური ან სტატიკური ბიბლიოთეკის სახით;

ცხრილი - ასევე განსაზღვრავს კომპონენტის პირველ ტიპს, რომელიც წარმოდგენილია მონაცემთა ბაზის ცხრილის სახით;

ფაილი (ფაილი) - განსაზღვრავს მეორე ტიპის კომპონენტს, რომელიც წარმოდგენილია ფაილების სახით პროგრამების საწყისი კოდით;

დოკუმენტი - განსაზღვრავს მეორე ტიპის კომპონენტს, . რომელიც წარმოდგენილია დოკუმენტის სახით;

შესრულებადი - განსაზღვრავს მესამე ტიპის კომპონენტს, რომელიც შეიძლება შესრულდეს კვანძში.

ინტერფეისები

კომპონენტის დიაგრამის შემდეგი ელემენტია ინტერფეისები. ზოგადად, ინტერფეისი გრაფიკულად არის წარმოდგენილი წრით, რომელიც დაკავშირებულია კომპონენტთან ხაზის სეგმენტით ისრების გარეშე. ინტერფეისის სახელი უნდა დაიწყოს დიდი ასოთი "I" და დაიწეროს წრის გვერდით. სემანტიკურად, ხაზი ნიშნავს ინტერფეისის განხორციელებას, ხოლო კომპონენტზე ინტერფეისების არსებობა ნიშნავს, რომ ეს კომპონენტი ახორციელებს ინტერფეისების შესაბამის კომპლექტს.

კომპონენტის დიაგრამაში ინტერფეისის წარმოდგენის კიდევ ერთი გზაა მისი გამოსახვა კლასის მართკუთხედად "ინტერფეისის" სტერეოტიპით და შესაძლო ატრიბუტით და ოპერაციული სექციებით. როგორც წესი, ეს აღნიშვნა გამოიყენება ინტერფეისის შიდა სტრუქტურის წარმოსაჩენად, რაც შეიძლება მნიშვნელოვანი იყოს განხორციელებისთვის.

პროგრამული სისტემების შემუშავებისას, ინტერფეისები უზრუნველყოფენ არა მხოლოდ თავსებადობას სხვადასხვა ვერსიებს შორის, არამედ პროგრამის ზოგიერთ ნაწილში მნიშვნელოვანი ცვლილებების შეტანის შესაძლებლობას სხვა ნაწილების შეცვლის გარეშე. ამრიგად, ინტერფეისების დანიშნულება ბევრად უფრო ფართოა, ვიდრე სისტემის მომხმარებლებთან (აქტორებთან) ურთიერთქმედების სპეციფიკაცია.

დამოკიდებულებები

ზოგადად, დამოკიდებულების მიმართებაც ადრე იყო განხილული. შეგახსენებთ, რომ დამოკიდებულება არ არის ასოციაცია, არამედ ემსახურება მხოლოდ ასეთი კავშირის არსებობის ფაქტის წარმოდგენას, როდესაც მოდელის ერთი ელემენტის ცვლილება გავლენას ახდენს ან იწვევს მოდელის სხვა ელემენტის ცვლილებას. კომპონენტის დიაგრამაში დამოკიდებულების ურთიერთობა წარმოდგენილია წერტილოვანი ხაზით კლიენტიდან (დამოკიდებული ელემენტი) წყაროსკენ (დამოუკიდებელ ელემენტზე) მიმართული ისრით.

დამოკიდებულებებს შეუძლია ასახოს კავშირები პროგრამის მოდულებს შორის შედგენის ეტაპზე და ობიექტის კოდის გენერირება. ალტერნატიულად, დამოკიდებულება შეიძლება ასახავდეს კლასის განმარტებების დამოუკიდებელ კომპონენტში არსებობას, რომლებიც გამოიყენება დამოკიდებულ კომპონენტში შესაბამისი ობიექტების შესაქმნელად. კომპონენტის დიაგრამაზე გამოყენებისას, დამოკიდებულებებს შეუძლიათ დააკავშირონ კომპონენტები და ამ კომპონენტის მიერ იმპორტირებული ინტერფეისები, ასევე სხვადასხვა ტიპის კომპონენტები ერთმანეთთან.

პირველ შემთხვევაში, ისარი იწერება კლიენტის კომპონენტიდან იმპორტირებულ ინტერფეისამდე. ისრის არსებობა ნიშნავს, რომ კომპონენტი არ ახორციელებს შესაბამის ინტერფეისს, მაგრამ იყენებს მას შესრულების დროს. უფრო მეტიც, იგივე დიაგრამა შეიძლება შეიცავდეს სხვა კომპონენტს, რომელიც ახორციელებს ამ ინტერფეისს.

კომპონენტის დიაგრამაში დამოკიდებულების ურთიერთობის კიდევ ერთი მაგალითია სხვადასხვა სახის კომპონენტებს შორის ურთიერთობა. ასეთი დამოკიდებულების არსებობა ნიშნავს, რომ ცვლილებების შეტანა პროგრამების საწყის კოდში ან დინამიურ ბიბლიოთეკებში იწვევს ცვლილებებს თავად კომპონენტში. ამ შემთხვევაში, ცვლილებების ბუნება შეიძლება დამატებით აღინიშნოს.

კომპონენტის დიაგრამას ასევე შეუძლია წარმოადგინოს დამოკიდებულების ურთიერთობა კომპონენტებსა და მათ მიერ განხორციელებულ კლასებს შორის. ეს ინფორმაცია მნიშვნელოვანია სისტემის მოდელის ლოგიკურ და ფიზიკურ წარმოდგენებს შორის თანმიმდევრულობის უზრუნველსაყოფად. თუ გსურთ ხაზგასმით აღვნიშნოთ, რომ კომპონენტი ახორციელებს ცალკეულ კლასებს, მაშინ გაფართოებული მართკუთხედის სიმბოლო გამოიყენება კომპონენტის აღსანიშნავად. ამ შემთხვევაში, კომპონენტის ოთხკუთხედი იყოფა ორ ნაწილად ჰორიზონტალური ხაზით. ზედა განყოფილება გამოიყენება კომპონენტის სახელის ჩასაწერად, ხოლო ქვედა ნაწილი გამოიყენება დამატებითი ინფორმაციის მითითებისთვის.

გრაფიკული აღნიშვნის სხვა ელემენტები, როგორიცაა კლასები (ტიპის დონის კომპონენტი) ან ობიექტები (მაგალითის დონის კომპონენტი), შეიძლება იყოს გამოსახული კომპონენტის სიმბოლოში. ამ შემთხვევაში, კომპონენტის სიმბოლო შედგენილია ამ დამატებითი სიმბოლოების განსათავსებლად.

ობიექტები, რომლებიც ცხოვრობენ ცალკე ინსტანციის კომპონენტში, გამოსახულია როგორც ბუდებული ამ კომპონენტის სიმბოლოში. ასეთი ბუდე ნიშნავს, რომ კომპონენტის შესრულება გულისხმობს შესაბამისი ობიექტების შესრულებას.

კომპონენტის დიაგრამის შემუშავება გულისხმობს ინფორმაციის გამოყენებას როგორც სისტემის მოდელის ლოგიკური წარმოდგენის, ასევე მისი ფიზიკური განხორციელების მახასიათებლების შესახებ. განვითარების დაწყებამდე აუცილებელია გადაწყვეტილებების მიღება გამოთვლითი პლატფორმებისა და ოპერაციული სისტემების არჩევის შესახებ, რომლებზეც სისტემა უნდა განხორციელდეს, ასევე კონკრეტული მონაცემთა ბაზებისა და პროგრამირების ენების არჩევის შესახებ.

ამის შემდეგ შეგიძლიათ გააგრძელოთ კომპონენტის დიაგრამის ზოგადი სტრუქტურირება. უპირველეს ყოვლისა, აუცილებელია გადაწყვიტოს, თუ რა ფიზიკური ნაწილებისგან (ფაილებისგან) შედგება პროგრამული სისტემა. ამ ეტაპზე ყურადღება უნდა მიექცეს სისტემის იმპლემენტაციას, რომელიც უზრუნველყოფს არა მხოლოდ კოდის ხელახალი გამოყენების შესაძლებლობას კომპონენტების რაციონალური დაშლის გზით, არამედ ობიექტების შექმნას მხოლოდ საჭიროების შემთხვევაში.

საქმე იმაშია, რომ პროგრამული სისტემის მთლიანი შესრულება მნიშვნელოვნად არის დამოკიდებული გამოთვლითი რესურსების რაციონალურ გამოყენებაზე. ამ მიზნით, აუცილებელია კლასების აღწერილობების უმეტესი ნაწილი, მათი ოპერაციები და მეთოდები გადაიტანოთ დინამიურ ბიბლიოთეკებში, შესრულებად კომპონენტებში დატოვონ პროგრამის კოდის მხოლოდ ყველაზე საჭირო ფრაგმენტები პროგრამის ინიციალიზაციისთვის.

სისტემის ფიზიკური წარმოდგენის ზოგადი სტრუქტურირების შემდეგ, საჭიროა მოდელის შევსება ინტერფეისებით და მონაცემთა ბაზის სქემებით. ინტერფეისების შემუშავებისას ყურადღება უნდა მიაქციოთ პროგრამული სისტემის სხვადასხვა ნაწილების კოორდინაციას (შეერთებას). მონაცემთა ბაზის სქემის მოდელში ჩართვა გულისხმობს ცალკეული ცხრილების დაზუსტებას და ცხრილებს შორის ინფორმაციული ურთიერთობების დამყარებას.

კომპონენტის დიაგრამის აგების საბოლოო ეტაპი ასოცირდება დიაგრამაზე კომპონენტებს შორის ურთიერთკავშირების დამყარებასა და დახატვასთან, აგრეთვე განხორციელების ურთიერთობებთან. ეს ურთიერთობები უნდა ასახავდეს სისტემის ფიზიკური განხორციელების ყველა ყველაზე მნიშვნელოვან ასპექტს, დაწყებული პროგრამების წყაროს კოდების შედგენის მახასიათებლებით და დამთავრებული პროგრამის ცალკეული ნაწილების შესრულებით მისი შესრულების ეტაპზე. ამ მიზნით, შეგიძლიათ გამოიყენოთ კომპონენტების სხვადასხვა სახის გრაფიკული წარმოდგენა.

კომპონენტის დიაგრამის შემუშავებისას, თქვენ უნდა დაიცვან UML ენაზე მოდელების შექმნის ზოგადი პრინციპები. კერძოდ, აუცილებელია UML ენაზე უკვე არსებული კომპონენტებისა და სტერეოტიპების გამოყენება. ყველაზე ტიპიური პროექტებისთვის, ელემენტების ეს ნაკრები შეიძლება იყოს საკმარისი იმისათვის, რომ წარმოადგინოს კომპონენტები და მათ შორის დამოკიდებულებები.

თუ პროექტი შეიცავს ზოგიერთ ფიზიკურ ელემენტს, რომლებიც არ არის აღწერილი UML ენაზე, მაშინ უნდა გამოიყენოთ გაფართოების მექანიზმი და გამოიყენოთ დამატებითი სტერეოტიპები ცალკეული არატიპიური კომპონენტებისთვის ან ეტიკეტირებული მნიშვნელობებისთვის მათი ინდივიდუალური მახასიათებლების გასარკვევად.

უნდა აღინიშნოს, რომ კომპონენტის დიაგრამა ჩვეულებრივ შემუშავებულია განლაგების დიაგრამასთან ერთად, რომელიც გვაწვდის ინფორმაციას პროგრამული სისტემის კომპონენტების ფიზიკური განლაგების შესახებ მის ცალკეულ კვანძებში.

კომპონენტის დიაგრამა აჩვენებს პროგრამული სისტემის დიზაინის ნაწილებს. კომპონენტის დიაგრამა გვეხმარება სისტემის მაღალი დონის სტრუქტურისა და ამ ელემენტების მიერ მოწოდებული და მოხმარებული სერვისების ვიზუალიზაციაში ინტერფეისების საშუალებით. UML კომპონენტის დიაგრამის შესაქმნელად, არქიტექტურის მენიუში დააწკაპუნეთ დიაგრამის შექმნაზე.

კომპონენტის დიაგრამა შეიძლება გამოყენებულ იქნას სისტემის დიზაინის აღსაწერად, რომელიც განხორციელებულია ნებისმიერ ენაზე ან სტილში. საჭიროა მხოლოდ სტრუქტურის ნაწილების იდენტიფიცირება, რომლებიც ურთიერთქმედებენ სხვა ნაწილებთან შეყვანისა და გამომავალი არხების შეზღუდული ნაკრების საშუალებით. თქვენ შეგიძლიათ გამოიყენოთ ნებისმიერი მასშტაბის კომპონენტები, ურთიერთდაკავშირებული ნებისმიერი გზით.

შემდეგი ცხრილი აღწერს ელემენტებს, რომლებიც შეიძლება გამოყენებულ იქნას კომპონენტის დიაგრამაში და მათი ძირითადი თვისებები.

ფიგურა	ელემენტი	აღწერა და ძირითადი თვისებები
	Კომპონენტი	სისტემის მრავალჯერადი გამოყენების ფუნქციური ელემენტი. კომპონენტი ავლენს და მოიხმარს ქცევას ინტერფეისების საშუალებით და შეუძლია გამოიყენოს სხვა კომპონენტები. თქვენ შეგიძლიათ დამალოთ ან აჩვენოთ კომპონენტის შიდა ნაწილები გაფართოების/დაშლის კონტროლის გამოყენებით (9). კომპონენტი არის ერთგვარი კლასი. არის იმპლიციტურად შექმნილი ინსტანცია. თუ მართალია (ნაგულისხმევი), კომპონენტი არსებობს მხოლოდ როგორც დიზაინის არტეფაქტი. გაშვების დროს, მისი მხოლოდ ნაწილი არსებობს.
	მოწოდებული ინტერფეისის პორტი	წარმოადგენს შეტყობინებების ჯგუფს ან ზარებს, რომლებიც განხორციელებულია კომპონენტის მიერ და ხელმისაწვდომია სხვა კომპონენტების ან გარე სისტემებისთვის გამოსაყენებლად. პორტი არის კომპონენტის თვისება, რომელსაც აქვს ინტერფეისი, როგორც მისი ტიპი.
	საჭირო ინტერფეისის პორტი	წარმოადგენს შეტყობინებების ჯგუფს ან ზარებს, რომლებიც გაგზავნილია კომპონენტის მიერ სხვა კომპონენტებზე ან გარე სისტემებზე. კომპონენტი შექმნილია იმ კომპონენტებთან დასაკავშირებლად, რომლებიც უზრუნველყოფენ მინიმუმ ამ ოპერაციებს. პორტს აქვს ინტერფეისი, როგორც მისი ტიპი.
	დამოკიდებულება	შეიძლება გამოყენებულ იქნას იმის აღსანიშნავად, რომ ერთი კომპონენტის საჭირო ინტერფეისი შეიძლება ემთხვეოდეს სხვა კომპონენტის მოწოდებულ ინტერფეისს. დამოკიდებულებები ასევე შეიძლება გამოყენებულ იქნას უფრო ზოგადად მოდელის ელემენტებთან მუშაობისას, რათა აჩვენოს, რომ ერთის დიზაინი დამოკიდებულია მეორის დიზაინზე.
		კომპონენტის ატრიბუტი, რომლის ტიპი, როგორც წესი, სხვა კომპონენტია. ნაწილი გამოიყენება მისი მთავარი კომპონენტის შიდა დიზაინში. გრაფიკულად, ნაწილები ნაჩვენებია, როგორც ჩასმული ძირითადი კომპონენტის შიგნით. არსებული კომპონენტის ტიპის ნაწილის შესაქმნელად, გადაიტანეთ კომპონენტი UML Model Explorer-დან მფლობელ კომპონენტზე. ახალი ტიპის ნაწილის შესაქმნელად აირჩიეთ კომპონენტი ინსტრუმენტი და დააწკაპუნეთ მფლობელ კომპონენტზე. მაგალითად, მანქანის კომპონენტს აქვს ნაწილების ძრავა: CarEngine, უკანა მარცხნივ: საჭე, წინამარჯვნივ: საჭე და ა.შ. მრავალი ნაწილი შეიძლება იყოს ერთი და იგივე ტიპის, ხოლო სხვადასხვა კომპონენტს შეიძლება ჰქონდეს იგივე ტიპის ნაწილები. ტიპი. მოდელის სხვაგან განსაზღვრული ნაწილის ტიპი. როგორც წესი, ტიპი სხვა კომპონენტია. სიმრავლე. ნაგულისხმევი მნიშვნელობა არის 1. შეგიძლიათ დააყენოთ ის 0..1-ზე, რათა მიუთითოთ, რომ ნაწილი შეიძლება იყოს null, ან შეგიძლიათ დააყენოთ *-ზე, რათა მიუთითოთ, რომ ნაწილი არის ამ ტიპის ინსტანციების კოლექცია. თქვენ ასევე შეგიძლიათ დააყენოთ მნიშვნელობა ნებისმიერი გამოხატვისთვის, რომელიც შეიძლება შეფასდეს რიცხვითი დიაპაზონში.
	შეკრების ნაწილი	კავშირი ერთი ნაწილის საჭირო ინტერფეისის პორტებსა და მეორის მოწოდებულ ინტერფეისის პორტებს შორის. ნაწილების შეკრების განხორციელება შეიძლება განსხვავდებოდეს სხვადასხვა კომპონენტისთვის. დაკავშირებულ ნაწილებს უნდა ჰქონდეს იგივე ძირითადი კომპონენტი.
	დელეგაცია	აკავშირებს პორტს ერთ-ერთი კომპონენტის ინტერფეისთან. მიუთითებს, რომ კომპონენტზე გაგზავნილი შეტყობინებები მუშავდება ამ ნაწილის მიერ, ან რომ ამ ნაწილის მიერ გაგზავნილი შეტყობინებები იგზავნება მშობელი კომპონენტიდან.
(არ არის ნაჩვენები)	განზოგადება	მიუთითებს, რომ ერთი კომპონენტი მემკვიდრეობით იღებს მეორეს. ნაწილები და ინტერფეისები მემკვიდრეობით მიიღება.
	კონტროლის გაფართოება/ჩაკეცვა	საშუალებას გაძლევთ დამალოთ ან აჩვენოთ კომპონენტის შიდა ნაწილები.
(არ არის ნაჩვენები)

UML დიაგრამა არის სპეციალიზებული გრაფიკული აღწერილობის ენა, რომელიც შექმნილია ობიექტების მოდელირებისთვის სხვადასხვა პროგრამული უზრუნველყოფის შემუშავებაში. ენას აქვს ფართო პროფილი და არის ღია სტანდარტი, რომელიც იყენებს სხვადასხვა გრაფიკულ აღნიშვნებს სისტემის აბსტრაქტული მოდელის შესაქმნელად. UML შეიქმნა იმისათვის, რომ უზრუნველყოს ყველა სახის პროგრამული სისტემის განსაზღვრა, ვიზუალიზაცია, დოკუმენტაცია და დიზაინი. აღსანიშნავია, რომ UML დიაგრამა თავისთავად არ არის პროგრამირების ენა, მაგრამ იძლევა მასზე დაფუძნებული ცალკეული კოდის გენერირების შესაძლებლობას.

რატომ არის საჭირო?

UML-ის გამოყენება არ მთავრდება ყველა სახის პროგრამული უზრუნველყოფის მოდელირებით. ასევე, ეს ენა დღეს აქტიურად გამოიყენება სხვადასხვა ბიზნეს პროცესების მოდელირებისთვის, სისტემის დიზაინის ჩასატარებლად და ასევე ორგანიზაციული სტრუქტურების ჩვენებისთვის.

UML-ით, პროგრამული უზრუნველყოფის შემქმნელებს შეუძლიათ უზრუნველყონ სრული თანხმობა გრაფიკულ აღნიშვნაში, რომელიც გამოიყენება საერთო ცნებების წარმოსაჩენად, როგორიცაა: კომპონენტი, ზოგადი, კლასი, ქცევა და აგრეგაცია. ამის გამო, არქიტექტურასა და დიზაინზე უფრო დიდი კონცენტრაცია მიიღწევა.

აღსანიშნავია ისიც, რომ ასეთი სქემების რამდენიმე ტიპი არსებობს.

კლასის დიაგრამა

UML კლასის დიაგრამა არის სტატიკური სტრუქტურული დიაგრამა, რომელიც შექმნილია სისტემის სტრუქტურის აღწერისთვის, ასევე აჩვენოს ატრიბუტები, მეთოდები და დამოკიდებულებები რამდენიმე სხვადასხვა კლასს შორის.

აღსანიშნავია ის ფაქტი, რომ არსებობს რამდენიმე თვალსაზრისი ასეთი დიაგრამების აგების შესახებ, იმისდა მიხედვით, თუ როგორ გამოიყენებენ მათ:

• კონცეპტუალური. ამ შემთხვევაში, UML კლასის დიაგრამა აღწერს კონკრეტული საგნის არეალის მოდელს და ის უზრუნველყოფს მხოლოდ აპლიკაციის ობიექტების კლასებს.
• Კონკრეტული. დიაგრამა გამოიყენება სხვადასხვა საინფორმაციო სისტემების დიზაინის პროცესში.
• განხორციელება. კლასის დიაგრამა მოიცავს ყველა სახის კლასს, რომლებიც უშუალოდ გამოიყენება პროგრამის კოდში.

კომპონენტის დიაგრამა

UML კომპონენტის დიაგრამა არის სრულიად სტატიკური სტრუქტურის დიაგრამა. იგი მიზნად ისახავს კონკრეტული პროგრამული სისტემის დაშლის სხვადასხვა სტრუქტურულ კომპონენტებად დემონსტრირებას, ასევე მათ შორის კავშირებს. UML კომპონენტის დიაგრამას შეუძლია გამოიყენოს ყველა სახის მოდელი, ბიბლიოთეკა, ფაილი, პაკეტები, შესრულებადი ფაილები და მრავალი სხვა ელემენტი, როგორც ასეთი.

კომპოზიტური/კომპოზიტური სტრუქტურის დიაგრამა

UML კომპოზიტური/კომპოზიტური სტრუქტურის დიაგრამა ასევე არის სტატიკური სტრუქტურის დიაგრამა, მაგრამ ის გამოიყენება კლასების შიდა სტრუქტურის საჩვენებლად. თუ შესაძლებელია, ამ დიაგრამას ასევე შეუძლია აჩვენოს კლასის შიდა სტრუქტურაში მდებარე ელემენტების ურთიერთქმედება.

მათი ქვეტიპია UML თანამშრომლობის დიაგრამა, რომელიც გამოიყენება როლების დემონსტრირებისთვის, ასევე თანამშრომლობის საზღვრებში სხვადასხვა კლასის ურთიერთქმედების მიზნით. ისინი საკმაოდ მოსახერხებელია, თუ საჭიროა დიზაინის ნიმუშების მოდელირება.

აღსანიშნავია, რომ UML კლასის და კომპოზიტური სტრუქტურის დიაგრამის ხედების გამოყენება შესაძლებელია ერთდროულად.

განლაგების დიაგრამა

ეს დიაგრამა გამოიყენება გაშვებული კვანძების მოდელირებისთვის, ისევე როგორც ყველა სახის არტეფაქტისთვის, რომელიც მათზე იყო განლაგებული. UML 2-ში არტეფაქტები განლაგებულია სხვადასხვა კვანძზე, ხოლო პირველ ვერსიაში მხოლოდ კომპონენტები იყო განლაგებული. ამრიგად, UML განლაგების დიაგრამა ძირითადად გამოიყენება მეორე ვერსიისთვის.

მანიფესტაციური დამოკიდებულება იქმნება არტეფაქტსა და კომპონენტს შორის, რომელსაც ის ახორციელებს.

ობიექტის დიაგრამა

ეს ხედი საშუალებას გაძლევთ ნახოთ სისტემის სრული ან ნაწილობრივი სურათი, რომელიც იქმნება დროის გარკვეულ მომენტში. იგი სრულად აჩვენებს კონკრეტული სისტემის კლასების ყველა შემთხვევას, მიუთითებს მათი პარამეტრების მიმდინარე მნიშვნელობებზე, ასევე მათ შორის კავშირებზე.

პაკეტის დიაგრამა

ეს დიაგრამა სტრუქტურული ხასიათისაა და მისი ძირითადი შინაარსია ყველა სახის პაკეტი, ასევე მათ შორის ურთიერთობა. ამ შემთხვევაში, არ არსებობს მკაცრი დაყოფა რამდენიმე სტრუქტურულ დიაგრამას შორის, რის შედეგადაც მათი გამოყენება ყველაზე ხშირად გვხვდება მხოლოდ მოხერხებულობისთვის და არ ატარებს რაიმე სემანტიკურ მნიშვნელობას. აღსანიშნავია, რომ სხვადასხვა ელემენტებს შეუძლიათ უზრუნველყონ სხვა UML დიაგრამები (მაგალითები: პაკეტები და თავად პაკეტის დიაგრამები).

მათი გამოყენება ხორციელდება გარკვეული კრიტერიუმის მიხედვით რამდენიმე ელემენტის ჯგუფებად ორგანიზების უზრუნველსაყოფად, სტრუქტურის გამარტივების მიზნით, ასევე მოცემული სისტემის მოდელთან მუშაობის ორგანიზებისთვის.

აქტივობის დიაგრამა

UML აქტივობის დიაგრამა ასახავს კონკრეტული აქტივობის დაშლას რამდენიმე კომპონენტურ ნაწილად. ამ შემთხვევაში, „აქტივობის“ ცნება არის გარკვეული შესრულებადი ქცევის დაზუსტება პარალელური, ისევე როგორც სხვადასხვა დაქვემდებარებული ელემენტების კოორდინირებული თანმიმდევრული შესრულების სახით - ჩადგმული ტიპის აქტივობები და სხვადასხვა მოქმედებები, რომლებიც გაერთიანებულია გამომავალ ნაკადებით. გარკვეული კვანძის სხვის შეყვანაში.

UML აქტივობის დიაგრამები ხშირად გამოიყენება სხვადასხვა ბიზნეს პროცესების, პარალელური და თანმიმდევრული გამოთვლების მოდელირებისთვის. სხვა საკითხებთან ერთად, ისინი ახდენენ ყველა სახის ტექნოლოგიური პროცედურის სიმულაციას.

მანქანის დიაგრამა

ამ ტიპს ასევე ცოტა სხვანაირად უწოდებენ - UML მდგომარეობის დიაგრამა. მას აქვს წარმოდგენილი სასრული მდგომარეობის მანქანა მარტივი და კომპოზიტური მდგომარეობებით, ასევე გადასვლებით.

სახელმწიფო მანქანა არის სხვადასხვა მდგომარეობების თანმიმდევრობის სპეციფიკაცია, რომლის მეშვეობითაც გარკვეული ობიექტი ან ურთიერთქმედება გადის მის ცხოვრებაში გარკვეული მოვლენების საპასუხოდ, ისევე როგორც ობიექტის რეაქცია ასეთ მოვლენებზე. მდგომარეობის მანქანა, რომელიც იყენებს UML მდგომარეობის დიაგრამას, ერთვის წყაროს ელემენტს და გამოიყენება მისი ინსტანციების ქცევის დასადგენად.

ასეთი დიაგრამების ანალოგად შეიძლება გამოვიყენოთ ეგრეთ წოდებული დრაკონის დიაგრამები.

გამოიყენეთ შემთხვევების დიაგრამები

UML გამოყენების შემთხვევის დიაგრამა ასახავს ყველა ურთიერთობას, რომელიც ხდება მსახიობებს შორის, ისევე როგორც გამოყენების სხვადასხვა შემთხვევებს შორის. მისი მთავარი ამოცანაა უზრუნველყოს სრულფასოვანი საშუალება, რომლის საშუალებითაც მომხმარებელს, საბოლოო მომხმარებელს ან რომელიმე დეველოპერს ერთობლივად შეუძლიათ განიხილონ გარკვეული სისტემის ქცევა და ფუნქციონირება.

თუ UML გამოყენების შემთხვევის დიაგრამა გამოიყენება სისტემის მოდელირების პროცესში, მაშინ ანალიტიკოსი:

• აშკარად გამოყავით მოდელირებული სისტემა მისი გარემოსგან.
• იდენტიფიცირება მოქმედი პირები, მათი ამ სისტემასთან ურთიერთქმედების გზები, ასევე მისი მოსალოდნელი ფუნქციონირება.
• ლექსიკონში, როგორც საგნის არეალში, მითითებულია სხვადასხვა ცნებები, რომლებიც დაკავშირებულია მოცემული სისტემის ფუნქციონირების დეტალურ აღწერასთან.

თუ UML-ში შემუშავებულია გამოყენების დიაგრამა, პროცედურა იწყება ტექსტის აღწერით, რომელიც მიიღება მომხმარებელთან მუშაობისას. აღსანიშნავია ის ფაქტი, რომ გამოყენების შემთხვევაში მოდელის შედგენის პროცესში სრულიად გამოტოვებულია სხვადასხვა არაფუნქციური მოთხოვნები და მათთვის ცალკე დოკუმენტი შეიქმნება.

კომუნიკაციები

საკომუნიკაციო დიაგრამა, ისევე როგორც UML მიმდევრობის დიაგრამა, არის გარდამავალი, ანუ გამოხატავს ურთიერთქმედებას, მაგრამ ამავე დროს აჩვენებს მას სხვადასხვა გზით და, საჭიროების შემთხვევაში, შეიძლება გარდაიქმნას ერთიდან მეორეზე საჭირო სიზუსტით. .

საკომუნიკაციო დიაგრამა ასახავს ურთიერთქმედებებს, რომლებიც წარმოიქმნება კომპოზიციური სტრუქტურის სხვადასხვა ელემენტებს შორის, ისევე როგორც თანამშრომლობის როლებს. მთავარი განსხვავება მასსა და მიმდევრობის დიაგრამას შორის არის ის, რომ იგი საკმაოდ მკაფიო ხდის ურთიერთობას რამდენიმე ელემენტს შორის და არ იყენებს დროს, როგორც ცალკეულ განზომილებას.

ეს ტიპი გამოირჩევა აბსოლუტურად თავისუფალი ფორმატით რამდენიმე ობიექტისა და კავშირის მოწყობისთვის ისე, როგორც ეს ხდება ობიექტის დიაგრამაში. თუ საჭიროა ამ უფასო ფორმატში შეტყობინებების თანმიმდევრობის შენარჩუნება, ისინი დანომრილია ქრონოლოგიურად. ამ დიაგრამის წაკითხვა იწყება თავდაპირველი გზავნილით 1.0 და შემდგომში გრძელდება შეტყობინებების გადაცემის მიმართულებით ერთი ობიექტიდან მეორეზე.

უმეტესწილად, ეს დიაგრამები აჩვენებს ზუსტად იმავე ინფორმაციას, რასაც თანმიმდევრობის დიაგრამა გვაწვდის, მაგრამ რადგან ის იყენებს ინფორმაციის წარმოდგენის განსხვავებულ ხერხს, ერთ დიაგრამაში გარკვეული საგნების იდენტიფიცირება ბევრად უფრო ადვილი ხდება, ვიდრე მეორეში. აღსანიშნავია ისიც, რომ საკომუნიკაციო დიაგრამა უფრო ნათლად აჩვენებს, თუ რა ელემენტებთან ურთიერთქმედებს თითოეული ცალკეული ელემენტი, ხოლო თანმიმდევრობის დიაგრამა უფრო ნათლად აჩვენებს, თუ რა თანმიმდევრობით ხდება ურთიერთქმედება.

თანმიმდევრობის დიაგრამა

UML მიმდევრობის დიაგრამა გვიჩვენებს ურთიერთქმედებას მრავალ ობიექტს შორის, რომლებიც დალაგებულია მათი წარმოშობის დროის მიხედვით. ეს დიაგრამა გვიჩვენებს დროში მოწესრიგებულ ურთიერთქმედებას რამდენიმე ობიექტს შორის. კერძოდ, ის აჩვენებს ყველა ობიექტს, რომლებიც მონაწილეობენ ურთიერთქმედებაში, ასევე მათ შორის გაცვლილი შეტყობინებების სრულ თანმიმდევრობას.

ამ შემთხვევაში ძირითადი ელემენტებია სხვადასხვა ობიექტების აღნიშვნები, ასევე ვერტიკალური ხაზები, რომლებიც ასახავს დროის მსვლელობას და მართკუთხედებს, რომლებიც წარმოადგენს გარკვეული ობიექტის აქტივობას ან რაიმე ფუნქციის შესრულებას.

თანამშრომლობის დიაგრამა

ამ ტიპის დიაგრამა საშუალებას გაძლევთ აჩვენოთ ურთიერთქმედება რამდენიმე ობიექტს შორის, აბსტრაქტული შეტყობინების გადაცემის თანმიმდევრობიდან. ამ ტიპის დიაგრამა კომპაქტურად ასახავს გარკვეული ობიექტის აბსოლუტურად ყველა გადაცემულ და მიღებულ შეტყობინებას, ისევე როგორც ამ შეტყობინებების ფორმატებს.

იმის გამო, რომ თანმიმდევრობა და საკომუნიკაციო დიაგრამები უბრალოდ ერთი და იგივე პროცედურების განსხვავებული ხედია, Rational Rose იძლევა შესაძლებლობას შექმნას საკომუნიკაციო დიაგრამა მიმდევრობის დიაგრამიდან ან პირიქით, და ასევე ახდენს მათ სინქრონიზაციას მთლიანად ავტომატურად.

ურთიერთქმედების მიმოხილვის დიაგრამები

ეს არის UML დიაგრამები, რომლებიც წარმოადგენს აქტივობის დიაგრამის ტიპს და მოიცავს როგორც Sequence ელემენტებს, ასევე საკონტროლო ნაკადის კონსტრუქციებს.

აღსანიშნავია ის ფაქტი, რომ ეს ფორმატი აერთიანებს კოლაბორაციისა და თანმიმდევრობის დიაგრამას, რაც იძლევა შესაძლებლობას განიხილოს სხვადასხვა კუთხით ჩამოყალიბებული სისტემის რამდენიმე ობიექტის ურთიერთქმედება.

დროის დიაგრამა

წარმოადგენს თანმიმდევრობის დიაგრამის ალტერნატიულ ვერსიას, რომელიც ცალსახად აჩვენებს მდგომარეობის ცვლილებას სიცოცხლის ხაზის გასწვრივ კონკრეტულ დროში. შეიძლება საკმაოდ სასარგებლო იყოს სხვადასხვა რეალურ დროში აპლიკაციებში.

რა უპირატესობა აქვს?

აღსანიშნავია რამდენიმე უპირატესობა, რომელიც განასხვავებს UML გამოყენების დიაგრამას და სხვებს:

• ენა არის ობიექტზე ორიენტირებული, რის შედეგადაც ანალიზისა და დიზაინის შედეგების აღწერის ტექნოლოგიები სემანტიკურად ახლოსაა პროგრამირების მეთოდებთან ყველა სახის თანამედროვე ობიექტზე ორიენტირებულ ენაში.
• ამ ენის გამოყენებით, სისტემა შეიძლება აღწერილი იყოს თითქმის ნებისმიერი შესაძლო კუთხით და მისი ქცევის სხვადასხვა ასპექტი აღწერილია იმავე გზით.
• ყველა დიაგრამა შედარებით ადვილად იკითხება მისი სინტაქსის შედარებით სწრაფი გაცნობის შემდეგაც კი.
• UML საშუალებას გაძლევთ გააფართოვოთ და ასევე დანერგოთ თქვენი საკუთარი გრაფიკული და ტექსტური სტერეოტიპები, რაც ხელს უწყობს მის გამოყენებას არა მხოლოდ პროგრამული უზრუნველყოფის ინჟინერიაში.
• ენა საკმაოდ გავრცელდა და ასევე საკმაოდ აქტიურად ვითარდება.

ხარვეზები

იმისდა მიუხედავად, რომ UML დიაგრამების შექმნას ბევრი უპირატესობა აქვს, მათ ხშირად აკრიტიკებენ შემდეგი უარყოფითი მხარეების გამო:

• ჭარბი რაოდენობა. უმეტეს შემთხვევაში, კრიტიკოსები ამბობენ, რომ UML ძალიან დიდი და რთულია და ეს ხშირად გაუმართლებელია. იგი მოიცავს საკმაოდ ბევრ ზედმეტ ან პრაქტიკულად უსარგებლო დიზაინს და დიაგრამას, და ყველაზე ხშირად ასეთი კრიტიკა მიმართულია მეორე ვერსიაზე და არა პირველზე, რადგან ახალი გადასინჯვები შეიცავს უფრო მეტ კომპრომისებს „კომიტეტის მიერ შემუშავებულ“.
• სხვადასხვა უზუსტობა სემანტიკაში. იმის გამო, რომ UML განისაზღვრება მისი, ინგლისურისა და OCL-ის კომბინაციით, მას არ გააჩნია სიხისტე, რომელიც თანდაყოლილია ენებში, რომლებიც ზუსტად არის განსაზღვრული ფორმალური აღწერის ტექნიკით. გარკვეულ სიტუაციებში, OCL, UML და ინგლისური აბსტრაქტული სინტაქსი იწყებს ერთმანეთს ეწინააღმდეგება, ხოლო სხვა შემთხვევებში ისინი არასრულია. თავად ენის სპეციფიკაციის უზუსტობა გავლენას ახდენს როგორც მომხმარებლებზე, ასევე ხელსაწყოების გამყიდველებზე, რაც საბოლოოდ იწვევს ხელსაწყოების შეუთავსებლობას სხვადასხვა სპეციფიკაციების უნიკალური დამუშავების გამო.
• პრობლემები განხორციელებისა და შესწავლის პროცესში. ყველა ზემოაღნიშნული საკითხი ქმნის გამოწვევებს UML-ის დანერგვისა და სწავლისას, განსაკუთრებით მაშინ, როდესაც მენეჯმენტი აიძულებს ინჟინერებს გამოიყენონ იგი წინასწარი ცოდნის გარეშე.
• კოდი ასახავს კოდს. სხვა მოსაზრებაა, რომ მნიშვნელოვანია არა ლამაზი და მიმზიდველი მოდელები, არამედ თავად სამუშაო სისტემები, ანუ კოდი არის პროექტი. ამ შეხედულების მიხედვით, საჭიროა პროგრამული უზრუნველყოფის დაწერის უფრო ეფექტური ხერხის შემუშავება. UML ჩვეულებრივ ფასდება მიდგომებში, რომლებიც ადგენენ მოდელებს შესრულებადი ან წყარო კოდის რეგენერაციისთვის. მაგრამ სინამდვილეში, ეს შეიძლება არ იყოს საკმარისი, რადგან ენას არ გააჩნია ტურინგის სისრულის თვისებები და თითოეული გენერირებული კოდი საბოლოოდ შემოიფარგლება იმით, რისი გამოცნობა ან განსაზღვრა შეუძლია UML ინტერპრეტაციის ხელსაწყოს.
• ჩატვირთვის შეუსაბამობა. ეს ტერმინი მომდინარეობს სისტემური ანალიზის თეორიიდან, რათა დადგინდეს გარკვეული სისტემის შეყვანის შეუძლებლობა სხვა გამოსავლის აღქმაში. როგორც ნებისმიერი სტანდარტული აღნიშვნის შემთხვევაში, UML-ს შეუძლია წარმოადგინოს ზოგიერთი სისტემა უფრო ეფექტურად და მოკლედ, ვიდრე სხვები. ამრიგად, დეველოპერი უფრო მეტად არის მიდრეკილი იმ გადაწყვეტილებებისკენ, რომლებიც უფრო კომფორტულია UML-ის ყველა ძლიერი მხარე, ისევე როგორც სხვა პროგრამირების ენების შერწყმაში. ეს პრობლემა უფრო აშკარაა, თუ განვითარების ენა არ შეესაბამება ობიექტზე ორიენტირებული მართლმადიდებლობის ძირითად პრინციპებს, ანუ ის არ ცდილობს იმუშაოს OOP-ის პრინციპების შესაბამისად.
• ცდილობს იყოს უნივერსალური. UML არის ზოგადი დანიშნულების მოდელირების ენა, რომელიც ცდილობს იყოს თავსებადი დღეს არსებულ ნებისმიერ დამუშავების ენასთან. მოცემული პროექტის კონტექსტში, იმისათვის, რომ საპროექტო ჯგუფმა მიაღწიოს საბოლოო მიზანს, აუცილებელია ამ ენის გამოსაყენებელი მახასიათებლების შერჩევა. გარდა ამისა, UML-ის ფარგლების შეზღუდვის შესაძლო გზები კონკრეტულ სფეროში არის ფორმალიზმი, რომელიც ბოლომდე არ არის გამოხატული და რომელიც თავად ექვემდებარება კრიტიკას.

ამრიგად, ამ ენის გამოყენება არ არის აქტუალური ყველა სიტუაციაში.

       . UML არის საინჟინრო ტექნიკის ერთობლიობა, რომელიც ადრე წარმატებით გამოიყენებოდა დიდი და რთული სისტემების მოდელირებისთვის

        UML-ის შემქმნელები წარმოადგენენ მას, როგორც პროგრამული სისტემების, ბიზნეს სისტემების და სხვადასხვა ხასიათის სხვა სისტემების განსაზღვრის, წარმოდგენის, დიზაინისა და დოკუმენტაციის ენას. UML განსაზღვრავს ნოტაციას და მეტამოდელს. ნოტაცია არის გრაფიკული ობიექტების კოლექცია, რომლებიც გამოიყენება მოდელებში; ეს არის სამოდელო ენის სინტაქსი.

        UML გთავაზობთ ექსპრესიულ ინსტრუმენტებს ვიზუალური მოდელების შესაქმნელად, რომლებიც:

• ერთნაირად ესმით პროექტში ჩართული ყველა დეველოპერი;
• წარმოადგენს პროექტის ფარგლებში კომუნიკაციის საშუალებას.

        ერთიანი მოდელირების ენა (UML):

• არ არის დამოკიდებული ობიექტზე ორიენტირებულ (OO) პროგრამირების ენებზე;
• არ არის დამოკიდებული გამოყენებული პროექტის განვითარების მეთოდოლოგიაზე;
• შეუძლია ნებისმიერი OO პროგრამირების ენის მხარდაჭერა.

        UML ღიაა და აქვს ძირითადი ბირთვის გაფართოების ინსტრუმენტები. UML შეიძლება გამოყენებულ იქნას კლასების, ობიექტების და კომპონენტების მნიშვნელოვნად აღსაწერად სხვადასხვა საგნობრივ სფეროებში, ხშირად ძალიან განსხვავებული ერთმანეთისგან.

UML დიაგრამები

        Rational Rose გთავაზობთ შემდეგი ტიპის დიაგრამებს სისტემის დიზაინერის განკარგულებაში, რომელთა თანმიმდევრული შექმნა საშუალებას გაძლევთ მიიღოთ სრული სურათი მთელი შემუშავებული სისტემისა და მისი ცალკეული კომპონენტების შესახებ:

• გამოიყენეთ ქეისის დიაგრამა;
• განლაგების დიაგრამა (ტოპოლოგიის დიაგრამები);
• Statechart დიაგრამა;
• ურთიერთქმედების დიაგრამა; აქტივობის დიაგრამა;
• თანმიმდევრობის დიაგრამა;
• თანამშრომლობის დიაგრამა;
• კლასის დიაგრამა;
• კომპონენტის დიაგრამა (კომპონენტური დიაგრამები);
• ქცევის დიაგრამები;
• აქტივობის დიაგრამა;
• განხორციელების დიაგრამები;

        თითოეული ეს დიაგრამა განსაზღვრავს სხვადასხვა იდეებს სისტემის მოდელის შესახებ. ამავდროულად, გამოყენების შემთხვევების დიაგრამა წარმოადგენს სისტემის კონცეპტუალურ მოდელს, რომელიც არის ამოსავალი წერტილი ყველა სხვა დიაგრამის ასაგებად. კლასის დიაგრამა არის ლოგიკური მოდელი, რომელიც ასახავს სისტემის სტრუქტურული დიზაინის სტატიკური ასპექტებს, ხოლო ქცევის დიაგრამები, რომლებიც ასევე ლოგიკური მოდელის ტიპებია, ასახავს მისი ფუნქციონირების დინამიურ ასპექტებს. განხორციელების დიაგრამები ემსახურება სისტემის კომპონენტების წარმოდგენას და მის ფიზიკურ მოდელს.

        ზემოთ ჩამოთვლილი დიაგრამებიდან ზოგიერთი ემსახურება ორი ან მეტი ქვესახეობის აღნიშვნას. შემდეგი დიაგრამები გამოიყენება როგორც დამოუკიდებელი წარმოდგენები: გამოყენების შემთხვევები, კლასები, მდგომარეობები, აქტივობები, თანმიმდევრობა, თანამშრომლობა, კომპონენტები და განლაგება.

        UML დიაგრამებისთვის არსებობს ვიზუალური სიმბოლოების სამი ტიპი, რომლებიც მნიშვნელოვანია მათში შემავალი ინფორმაციის თვალსაზრისით:

• კომუნიკაციები, რომლებიც წარმოდგენილია თვითმფრინავზე სხვადასხვა ხაზებით;
• ტექსტი, შეიცავს ცალკეული გეომეტრიული ფორმების საზღვრებს;
• გრაფიკული სიმბოლოები, გამოსახულია დიაგრამების ვიზუალურ ელემენტებთან.

        დიაგრამების გრაფიკული გამოსახვისას რეკომენდებულია შემდეგი წესების დაცვა:

• თითოეული დიაგრამა უნდა იყოს მოდელირებული საგნის არეალის ზოგიერთი ფრაგმენტის სრული წარმოდგენა;
• დიაგრამაზე წარმოდგენილი მოდელის ერთეულები უნდა იყოს იმავე კონცეპტუალური დონის;
• ყველა ინფორმაცია სუბიექტების შესახებ ნათლად უნდა იყოს წარმოდგენილი დიაგრამაზე;
• დიაგრამები არ უნდა შეიცავდეს ურთიერთსაწინააღმდეგო ინფორმაციას;
• დიაგრამები არ უნდა იყოს გადატვირთული ტექსტური ინფორმაციით;
• თითოეული დიაგრამა უნდა იყოს თვითკმარი ყველა მისი ელემენტის სწორი ინტერპრეტაციისთვის;
• კონკრეტული სისტემის აღწერისთვის საჭირო დიაგრამების ტიპების რაოდენობა არ არის მკაცრად დაფიქსირებული და განისაზღვრება დეველოპერის მიერ;
• სისტემის მოდელები უნდა შეიცავდეს მხოლოდ იმ ელემენტებს, რომლებიც განსაზღვრულია UML ნოტაციაში.

სუბიექტები UML-ში

        UML-ში განსაზღვრულია ოთხი ტიპის ერთეული: სტრუქტურული, ქცევითი, დაჯგუფება და ანოტაცია. ერთეულები არის ენის ძირითადი ობიექტზე ორიენტირებული ელემენტები, რომლებითაც იქმნება მოდელები.

        სტრუქტურული ერთეულებიარის არსებითი სახელები UML მოდელებში. როგორც წესი, ისინი წარმოადგენენ მოდელის სტატიკურ ნაწილებს, რომლებიც შეესაბამება სისტემის კონცეპტუალურ ან ფიზიკურ ელემენტებს. სტრუქტურული ერთეულების მაგალითებია "კლასი", "ინტერფეისი", "თანამშრომლობა", "გამოყენების შემთხვევა", "კომპონენტი", "კვანძი", "აქტორი".

        ქცევითი ერთეულებიარის UML მოდელის დინამიური კომპონენტები. ეს არის ზმნები, რომლებიც აღწერს მოდელის ქცევას დროსა და სივრცეში. ქცევითი ერთეულების ორი ძირითადი ტიპი არსებობს:

• ურთიერთქმედება არის ქცევა, რომლის არსი არის მესიჯების გაცვლა ობიექტებს შორის კონკრეტულ კონტექსტში კონკრეტული მიზნის მისაღწევად;
• ავტომატი - ქცევითი ალგორითმი, რომელიც განსაზღვრავს მდგომარეობების თანმიმდევრობას, რომლის მეშვეობითაც ობიექტი ან ურთიერთქმედება გადის სხვადასხვა მოვლენის საპასუხოდ.

        ერთეულების დაჯგუფებაარის UML მოდელის ორგანიზებული ნაწილები. ეს არის ბლოკები, რომლებშიც მოდელი შეიძლება დაიშალა. ასეთი პირველადი ერთეული არსებობს ერთ ეგზემპლარად - ეს არის პაკეტი.

        პაკეტები არის უნივერსალური მექანიზმი ელემენტების ჯგუფებად ორგანიზებისთვის. სტრუქტურული, ქცევითი და სხვა დაჯგუფების ერთეულები შეიძლება განთავსდეს პაკეტში. კომპონენტებისგან განსხვავებით, რომლებიც რეალურად არსებობენ პროგრამის გაშვებისას, პაკეტები წმინდა კონცეპტუალური ხასიათისაა, ანუ ისინი არსებობენ მხოლოდ განვითარების პროცესში.

        ანოტაციის პირები- ეს არის UML მოდელის განმარტებითი ნაწილები: კომენტარები დამატებითი აღწერისთვის, განმარტებისთვის ან შენიშვნები მოდელის ნებისმიერ ელემენტზე. არსებობს მხოლოდ ერთი ძირითადი ტიპის ანოტაციის ელემენტი - შენიშვნა. შენიშვნები გამოიყენება დიაგრამების უზრუნველსაყოფად კომენტარებით ან შეზღუდვებით, გამოხატული არაფორმალური ან ოფიციალური ტექსტით.

ურთიერთობები UML-ში

        შემდეგი ტიპის ურთიერთობები განსაზღვრულია UML ენაზე: დამოკიდებულება, ასოციაცია, განზოგადება და განხორციელება. ეს ურთიერთობები არის UML-ის მთავარი დამაკავშირებელი კონსტრუქტები და ასევე გამოიყენება როგორც ერთეულები მოდელების შესაქმნელად.

        Დამოკიდებულება- ეს არის სემანტიკური ურთიერთობა ორ ერთეულს შორის, რომლის დროსაც ერთ-ერთ მათგანში ცვლილებამ, დამოუკიდებელმა, შეიძლება გავლენა მოახდინოს მეორის, დამოკიდებულის სემანტიკაზე.

        ასოციაცია- სტრუქტურული ურთიერთობა, რომელიც აღწერს ობიექტებს შორის სემანტიკური ან ლოგიკური კავშირების ერთობლიობას.

        განზოგადებაარის ურთიერთობა, რომელშიც სპეციალიზებული ელემენტის ობიექტი (შთამომავალი) შეიძლება შეიცვალოს ზოგადი ელემენტის ობიექტით (წინაპარი). ამავდროულად, ობიექტზე ორიენტირებული პროგრამირების პრინციპების შესაბამისად, შთამომავალი (შვილი) მემკვიდრეობით იღებს თავისი წინაპრის (მშობლის) სტრუქტურას და ქცევას.

        რეალიზაციაარის სემანტიკური ურთიერთობა კლასიფიკატორებს შორის, რომელშიც ერთი კლასიფიკატორი განსაზღვრავს ვალდებულებას, ხოლო მეორე უზრუნველყოფს მის შესრულებას. განხორციელების ურთიერთობები ხდება ორ შემთხვევაში:

• ინტერფეისებსა და კლასებსა თუ კომპონენტებს შორის, რომლებიც ახორციელებენ მათ;
• პრეცედენტებსა და მათ განხორციელებულ თანამშრომლობას შორის.

საერთო UML მექანიზმები

        UML-ში სისტემის ზუსტად აღწერისთვის გამოიყენება ეგრეთ წოდებული ზოგადი მექანიზმები:

• სპეციფიკაციები;
• დანამატები (მორთულობები);
• საერთო განყოფილებები;
• გაფართოებები (გაფართოების მექანიზმები).

        UML არ არის მხოლოდ გრაფიკული ენა. თითოეული გრაფიკული ელემენტის უკან არის მისი აღნიშვნა სპეციფიკაცია, რომელიც შეიცავს შესაბამისი ენის კონსტრუქციის ტექსტურ წარმოდგენას. მაგალითად, კლასის ხატულას აქვს სპეციფიკაცია, რომელიც აღწერს მის ატრიბუტებს, ოპერაციებს და ქცევას, თუმცა ვიზუალურად, დიაგრამაში, ხატი ხშირად ასახავს ამ ინფორმაციის მხოლოდ მცირე ნაწილს. უფრო მეტიც, მოდელი შეიძლება შეიცავდეს ამ კლასის განსხვავებულ წარმოდგენას, რომელიც ასახავს მის სრულიად განსხვავებულ ასპექტებს, მაგრამ, მიუხედავად ამისა, შეესაბამება სპეციფიკაციას. ამრიგად, UML გრაფიკული აღნიშვნა გამოიყენება სისტემის ვიზუალიზაციისთვის და სპეციფიკაციების გამოყენებით მისი დეტალების აღსაწერად.

        თითქმის ყველა UML ელემენტს აქვს უნიკალური გრაფიკული გამოსახულება, რომელიც იძლევა მისი ყველაზე მნიშვნელოვანი მახასიათებლების ვიზუალურ წარმოდგენას. ერთეულის აღნიშვნა „კლასი“ შეიცავს მის სახელს, ატრიბუტებსა და ოპერაციებს. კლასის სპეციფიკაცია შეიძლება შეიცავდეს სხვა დეტალებს, როგორიცაა ატრიბუტებისა და ოპერაციების ხილვადობა, კომენტარები ან მითითება, რომ კლასი აბსტრაქტულია. ამ დეტალებიდან ბევრი შეიძლება ვიზუალურად იყოს წარმოდგენილი, როგორც გრაფიკა ან ტექსტი. დამატებებისტანდარტულ მართკუთხედს, რომელიც წარმოადგენს კლასს.

        ობიექტზე ორიენტირებული სისტემების მოდელირებისას არსებობს გარკვეული დაყოფაწარმოდგენილი სუბიექტები.

        პირველ რიგში, არის დაყოფა კლასებად და ობიექტებად. კლასი არის აბსტრაქცია, ხოლო ობიექტი არის ამ აბსტრაქციის კონკრეტული განსახიერება. ამ მხრივ თითქმის ყველა ენობრივი კონსტრუქტი ხასიათდება კლასის/ობიექტის ორმაგობით. ამრიგად, არსებობს პრეცედენტების პრეცედენტები და შემთხვევები, კომპონენტების კომპონენტები და შემთხვევები, კვანძები და კვანძების შემთხვევები. გრაფიკული წარმოდგენისას, ჩვეულებრივია გამოიყენოს იგივე სიმბოლო ობიექტისთვის, როგორც კლასისთვის, და ხაზი გაუსვას სახელს.

        მეორეც, არის ინტერფეისის დაყოფა და მისი განხორციელება. ინტერფეისი აცხადებს ვალდებულებებს, ხოლო იმპლემენტაცია წარმოადგენს ამ ვალდებულებების კონკრეტულ განხორციელებას და უზრუნველყოფს დეკლარირებული სემანტიკის ზუსტად დაცვას. ამის გამო, თითქმის ყველა UML კონსტრუქცია ხასიათდება ინტერფეისით/განხორციელების ორმაგობით. მაგალითად, პრეცედენტები ხორციელდება თანამშრომლობით, ხოლო ოპერაციები - მეთოდებით.

        UML არის ღია ენა, ანუ ის საშუალებას აძლევს კონტროლირებად გაფართოებებს ასახოს დომენის მოდელების მახასიათებლები.

        UML გაფართოების მექანიზმები მოიცავს:

• სტერეოტიპები (სტერეოტიპი) - გააფართოვეთ UML ლექსიკა, რაც საშუალებას გაძლევთ შექმნათ ახლები არსებული ენის ელემენტებზე დაყრდნობით, ორიენტირებული კონკრეტული პრობლემის გადაჭრაზე;
• მონიშნული მნიშვნელობები - აფართოებს UML-ის ძირითადი კონსტრუქციების თვისებებს, რაც საშუალებას აძლევს დამატებით ინფორმაციას შეიტანოს ელემენტის სპეციფიკაციაში;
• შეზღუდვები (შეზღუდვები) - გააფართოვეთ UML კონსტრუქციების სემანტიკა, რაც საშუალებას გაძლევთ შექმნათ ახალი და გააუქმოთ არსებული წესები.

        ერთად, ეს სამი ენის გაფართოების მექანიზმი საშუალებას გაძლევთ შეცვალოთ იგი პროექტის საჭიროებების ან განვითარების ტექნოლოგიის მახასიათებლების შესაბამისად.

გამოიყენეთ საქმის დიაგრამა

        ამ ტიპის დიაგრამა საშუალებას გაძლევთ შექმნათ ოპერაციების სია, რომლებსაც სისტემა ასრულებს. ხშირად ამ ტიპის დიაგრამას უწოდებენ ფუნქციის დიაგრამას, რადგან ასეთი დიაგრამების ნაკრების საფუძველზე იქმნება სისტემის მოთხოვნების ჩამონათვალი და განისაზღვრება სისტემის მიერ შესრულებული ფუნქციების ნაკრები.

სურათი - 1. გამოყენების შემთხვევაში დიაგრამა

        გამოყენების შემთხვევების დიაგრამები აღწერს სისტემის ფუნქციონირებას ან რას უნდა გააკეთოს სისტემამ. დიაგრამის შემუშავებას აქვს შემდეგი მიზნები:

• მოდელირებული საგნის არეალის ზოგადი საზღვრების და კონტექსტის განსაზღვრა;
• დაპროექტებული სისტემის ფუნქციონალური ქცევის ზოგადი მოთხოვნების ფორმულირება;
• სისტემის საწყისი კონცეპტუალური მოდელის შემუშავება მისი შემდგომი დეტალებისთვის ლოგიკური და ფიზიკური მოდელების სახით;
• მოამზადოს საწყისი დოკუმენტაცია სისტემის დეველოპერების მის მომხმარებლებთან და მომხმარებლებთან ურთიერთობისთვის.

        გამოყენების შემთხვევის დიაგრამის არსი შემდეგია. შემუშავებული სისტემა წარმოდგენილია როგორც ერთეულების ან აქტორების ერთობლიობა, რომლებიც ურთიერთქმედებენ სისტემასთან გამოყენების შემთხვევების მეშვეობით. ამ შემთხვევაში, აქტორი ან აქტორი არის ნებისმიერი სუბიექტი, რომელიც ურთიერთქმედებს სისტემასთან გარედან. ეს შეიძლება იყოს ადამიანი, ტექნიკური მოწყობილობა, პროგრამა ან ნებისმიერი სხვა სისტემა, რომელიც შეიძლება გახდეს ზემოქმედების წყარო იმ სიმულაციურ სისტემაზე, როგორც ამას თავად დეველოპერი განსაზღვრავს. Გამოყენების შემთხვევაშიემსახურება იმ სერვისების აღწერას, რომლებსაც სისტემა უწევს აქტორს.

        გამოყენების შემთხვევის მიზანია განსაზღვროს ზოგიერთი ერთეულის ქცევის სრული ასპექტი ან ფრაგმენტი მისი შიდა სტრუქტურის გამოვლენის გარეშე. ასეთი ერთეული შეიძლება იყოს სისტემა ან მოდელის ნებისმიერი ელემენტი, რომელსაც აქვს საკუთარი ქცევა.

        თითოეული გამოყენების შემთხვევა შეესაბამება ცალკეულ სერვისს, რომელსაც მოდელირებული ერთეული უზრუნველყოფს აქტორის მოთხოვნით, ანუ ის განსაზღვრავს, თუ როგორ იქნება გამოყენებული ეს ერთეული. სერვისი, რომელიც ინიციალიზებულია მსახიობის მოთხოვნით, არის მოქმედებების სრული, განუყოფელი თანმიმდევრობა. ეს ნიშნავს, რომ მას შემდეგ რაც სისტემა დაასრულებს მოთხოვნის დამუშავებას, ის უნდა დაუბრუნდეს პირვანდელ მდგომარეობას, რათა მზად იყოს შემდგომი მოთხოვნების დასამუშავებლად.

        გამოყენების შემთხვევები შეიძლება გამოყენებულ იქნას როგორც შემუშავებული სისტემის გარე მოთხოვნების დასაზუსტებლად, ასევე არსებული სისტემის ფუნქციონალური ქცევის დასაზუსტებლად. გამოყენების შემთხვევები მთლიანობაში უნდა განსაზღვროს სისტემის მოსალოდნელი ქცევის ყველა შესაძლო ასპექტი. გარდა ამისა, გამოყენების შემთხვევები ირიბად აწესებს მოთხოვნებს, რომლებიც განსაზღვრავს, თუ როგორ უნდა დაუკავშირდნენ აქტორებს სისტემასთან, რათა შეძლონ მოწოდებული სერვისების სწორად ფუნქციონირება. მოხერხებულობისთვის, გამოყენების მრავალი შემთხვევა შეიძლება განიხილებოდეს როგორც ცალკე პაკეტი.

        გამოყენების შემთხვევების მაგალითები შეიძლება მოიცავდეს შემდეგ ქმედებებს: კლიენტის მიმდინარე ანგარიშის სტატუსის შემოწმება, საქონლის შესყიდვის შეკვეთის განთავსება, კლიენტის კრედიტუნარიანობის შესახებ დამატებითი ინფორმაციის მიღება, მონიტორის ეკრანზე გრაფიკული ფორმის ჩვენება და სხვა. მოქმედებები.

კლასის დიაგრამა

        ობიექტზე ორიენტირებული პროგრამირების ცენტრალური ადგილია სისტემის ლოგიკური მოდელის შემუშავება კლასის დიაგრამის სახით. კლასის დიაგრამა გამოიყენება სისტემის მოდელის სტატიკური სტრუქტურის წარმოსაჩენად ობიექტზე ორიენტირებული პროგრამირების კლასების ტერმინოლოგიაში. კლასის დიაგრამას შეუძლია ასახოს, კერძოდ, სხვადასხვა ურთიერთობები ცალკეულ დომენურ ერთეულებს შორის, როგორიცაა ობიექტები და ქვესისტემები, ასევე აღწეროს მათი შიდა სტრუქტურა და ურთიერთობების ტიპები.

სურათი - 2. კლასის დიაგრამა

        დიაგრამის ხატები საშუალებას გაძლევთ აჩვენოთ სისტემების რთული იერარქია, ურთიერთობები კლასებს (კლასებს) და ინტერფეისებს (ინტერფეისებს) შორის. ამ ტიპის დიაგრამა შინაარსით ეწინააღმდეგება კოლაბორაციის დიაგრამას, რომელიც აჩვენებს სისტემის ობიექტებს. რაციონალური ვარდი საშუალებას გაძლევთ შექმნათ კლასები ამ ტიპის დიაგრამის გამოყენებით სხვადასხვა ნოტაციით. ღრუბლის მსგავსი. ამრიგად, კლასი მხოლოდ შაბლონია, რომლის მიხედვითაც მომავალში შეიქმნება კონკრეტული ობიექტი.

        კლასის დიაგრამა არის გრაფიკი, რომლის წვეროები არის "კლასიფიკატორის" ტიპის ელემენტები, რომლებიც დაკავშირებულია სხვადასხვა ტიპის სტრუქტურული ურთიერთობებით. კლასის დიაგრამა ასევე შეიძლება შეიცავდეს ინტერფეისებს, პაკეტებს, ურთიერთობებს და ცალკეულ ინსტანციებსაც კი, როგორიცაა ობიექტები და ურთიერთობები.

        Კლასი UML ენაში ემსახურება ობიექტების ერთობლიობის აღნიშვნას, რომლებსაც აქვთ იგივე სტრუქტურა, ქცევა და ურთიერთობა სხვა კლასის ობიექტებთან. გრაფიკულად, კლასი გამოსახულია მართკუთხედის სახით, რომელიც დამატებით შეიძლება დაიყოს ჰორიზონტალური ხაზებით სექციებად ან მონაკვეთებად. ეს სექციები შეიძლება შეიცავდეს კლასის სახელს, ატრიბუტებს (ცვლადები) და ოპერაციებს (მეთოდები).

სახელმწიფო სქემა დიაგრამა

        UML-ში თითოეული მდგომარეობის დიაგრამა აღწერს გარკვეული კლასის ერთი ეგზემპლარის ყველა შესაძლო მდგომარეობას და მისი გადასვლის შესაძლო თანმიმდევრობებს ერთი მდგომარეობიდან მეორეში, ანუ ის მოდელირებს ობიექტის მდგომარეობებში არსებულ ყველა ცვლილებას, როგორც მის პასუხს გარეზე. გავლენა.

        მდგომარეობის დიაგრამები ყველაზე ხშირად გამოიყენება ცალკეული ობიექტების ქცევის აღსაწერად, მაგრამ ასევე შეიძლება გამოყენებულ იქნას სხვა მოდელის კომპონენტების ფუნქციონალურობის დასადგენად, როგორიცაა გამოყენების შემთხვევები, აქტორები, ქვესისტემები, ოპერაციები და მეთოდები.

სურათი - 2. მდგომარეობის დიაგრამა

        მდგომარეობის დიაგრამა არის გრაფიკის სპეციალური ტიპი, რომელიც წარმოადგენს გარკვეულ ავტომატს. გრაფიკის წვეროები არის მანქანის შესაძლო მდგომარეობები, რომლებიც გამოსახულია შესაბამისი გრაფიკული სიმბოლოებით, ხოლო რკალი მიუთითებს მის გადასვლას მდგომარეობიდან მდგომარეობაზე. მდგომარეობის დიაგრამები შეიძლება იყოს ჩასმული მოდელის ცალკეული ელემენტების უფრო დეტალური წარმოდგენის უზრუნველსაყოფად.

        UML მეტამოდელში მანქანაარის პაკეტი, რომელიც განსაზღვრავს ბევრ კონცეფციას, რომელიც აუცილებელია მოდელირებული ერთეულის ქცევის წარმოსადგენად დისკრეტული სივრცის სახით, სასრული რაოდენობის მდგომარეობებითა და გადასვლებით.

        სისტემის ნებისმიერ შესაძლო მდგომარეობაში ყოფნის ხანგრძლივობა მნიშვნელოვნად აღემატება ერთი მდგომარეობიდან მეორეში გადასვლაზე დახარჯულ დროს. ვარაუდობენ, რომ ლიმიტში გარდამავალი დრო შეიძლება იყოს ნულის ტოლი (თუ სხვა რამ არ არის მითითებული), ანუ ობიექტის მდგომარეობის ცვლილება შეიძლება მოხდეს მყისიერად.

        ავტომატის ქცევა მოდელირებულია, როგორც გრაფაში თანმიმდევრული მოძრაობა წვეროდან წვერომდე, მათ შემაერთებელი რკალების ორიენტაციის გათვალისწინებით.

        შემდეგი სავალდებულო პირობები უნდა აკმაყოფილებდეს მანქანას:

• მდგომარეობა, რომელშიც შეიძლება შევიდეს ობიექტი, განისაზღვრება მხოლოდ მისი ამჟამინდელი მდგომარეობით და არ არის დამოკიდებული მის წინა ისტორიაზე;
• დროის ყოველ მომენტში ავტომატი შეიძლება იყოს მხოლოდ ერთ მდგომარეობაში. ამავდროულად, ავტომატი შეიძლება დარჩეს განცალკევებულ მდგომარეობაში რამდენ ხანს მოისურვება, თუ რაიმე მოვლენა არ მოხდება;
• მანქანის ამა თუ იმ მდგომარეობაში ყოფნის დრო, ისევე როგორც დრო, რომელიც სჭირდება ამა თუ იმ მდგომარეობის მიღწევას, არანაირად არ არის მითითებული;
• ავტომატის მდგომარეობების რაოდენობა უნდა იყოს სასრული და ყველა მათგანი მკაფიოდ უნდა იყოს მითითებული. ცალკეულ ფსევდოსახელმწიფოებს შეიძლება არ ჰქონდეთ სპეციფიკაციები (საწყისი და საბოლოო მდგომარეობები). ამ შემთხვევაში მათი დანიშნულება და სემანტიკა მთლიანად განისაზღვრება მოდელისა და განსახილველი მდგომარეობის დიაგრამის კონტექსტიდან;
• ავტომატური გრაფიკი არ უნდა შეიცავდეს იზოლირებულ მდგომარეობებს და გადასვლებს. თითოეული მდგომარეობისთვის, გარდა საწყისისა, უნდა განისაზღვროს წინა მდგომარეობა და ყოველი გადასვლა უნდა დააკავშიროს მანქანის ორ მდგომარეობას;
• ავტომატი არ უნდა შეიცავდეს კონფლიქტურ გადასვლებს, როდესაც ობიექტს შეუძლია ერთდროულად გადავიდეს ორ ან მეტ შემდგომ მდგომარეობაზე (გარდა პარალელური ქვეავტომატების შემთხვევისა). UML-ში კონფლიქტის აღმოფხვრა შესაძლებელია დაცვის პირობების შემოღებით.

სახელმწიფოფუნდამენტურია არა მხოლოდ UML ენის მეტამოდელში, არამედ გამოყენებითი სისტემების ანალიზშიც. დინამიური სისტემის მთელი კონცეფცია ეფუძნება სახელმწიფოს კონცეფციას. UML ენაში მდგომარეობის სემანტიკას აქვს რამდენიმე სპეციფიკური მახასიათებელი.

        UML-ში მდგომარეობა არის აბსტრაქტული მეტაკლასი, რომელიც გამოიყენება კონკრეტული სიტუაციის მოდელირებისთვის, რომლის დროსაც გარკვეული პირობები დაკმაყოფილებულია. მდგომარეობა შეიძლება განისაზღვროს, როგორც კონკრეტული კლასის ან ობიექტის ატრიბუტების მნიშვნელობების ნაკრები. ცალკეული ატრიბუტების მნიშვნელობებში ცვლილებები ასახავს ცვლილებებს მოდელირებული კლასის ან ობიექტის მდგომარეობაში.

აქტივობის დიაგრამა

        შემუშავებული ან გაანალიზებული სისტემის ქცევის მოდელირებისას საჭირო ხდება არა მხოლოდ მისი მდგომარეობის შეცვლის პროცესის წარმოდგენა, არამედ სისტემის მიერ შესრულებული ოპერაციების ალგორითმული და ლოგიკური განხორციელების მახასიათებლების დეტალური აღწერა.

        ფაქტობრივად, ამ ტიპის დიაგრამა ასევე შეიძლება გამოყენებულ იქნას მოდელირებული ობიექტის მდგომარეობების ასახვისთვის, თუმცა, Activity დიაგრამის მთავარი მიზანია ობიექტის ბიზნეს პროცესების ასახვა. ამ ტიპის დიაგრამა საშუალებას გაძლევთ აჩვენოთ არა მხოლოდ პროცესების თანმიმდევრობა, არამედ პროცესების განშტოება და თუნდაც სინქრონიზაცია.

        ამ ტიპის დიაგრამა საშუალებას გაძლევთ შეიმუშაოთ ალგორითმები ნებისმიერი სირთულის ობიექტების ქცევისთვის, მათ შორის შეიძლება გამოყენებულ იქნას ბლოკ-სქემების შედგენისთვის.

        UML ენაზე ოპერაციების შესრულების პროცესის მოდელირებისთვის გამოიყენება აქტივობის დიაგრამები. მათში გამოყენებული გრაფიკული აღნიშვნა მრავალი თვალსაზრისით ჰგავს მდგომარეობის დიაგრამის აღნიშვნას, ვინაიდან ეს დიაგრამები ასევე შეიცავს მდგომარეობისა და გარდამავალი სიმბოლოებს. აქტივობის დიაგრამაში თითოეული მდგომარეობა შეესაბამება ზოგიერთი ელემენტარული ოპერაციის დასრულებას და შემდეგ მდგომარეობაზე გადასვლა ხდება მხოლოდ ამ ოპერაციის დასრულების შემდეგ.

        ამრიგად, აქტივობის დიაგრამები შეიძლება ჩაითვალოს მდგომარეობის დიაგრამების განსაკუთრებულ შემთხვევად. ისინი საშუალებას გაძლევთ განახორციელოთ UML ენაზე პროცედურული და სინქრონული კონტროლის მახასიათებლები შიდა აქტივობებისა და მოქმედებების დასრულების გამო. აქტივობების დიაგრამების ძირითადი გამოყენებაა კლასის ოპერაციების განხორციელების მახასიათებლების ვიზუალიზაცია, როდესაც საჭიროა მათი განხორციელების ალგორითმების წარმოდგენა.

        UML ენის კონტექსტში აქტივობაარის ავტომატის მიერ შესრულებული ინდივიდუალური გამოთვლების ნაკრები, რაც იწვევს რაიმე შედეგს ან მოქმედებას. აქტივობის დიაგრამა აჩვენებს ერთი აქტივობიდან მეორეზე გადასვლის ლოგიკასა და თანმიმდევრობას და ანალიტიკოსის ყურადღებას ამახვილებს შედეგებზე. აქტივობის შედეგმა შეიძლება გამოიწვიოს სისტემის მდგომარეობის ცვლილება ან გარკვეული მნიშვნელობის დაბრუნება.

        მოქმედების მდგომარეობაარის სახელმწიფოს განსაკუთრებული შემთხვევა გარკვეული შეყვანის მოქმედებით და მდგომარეობიდან გასვლის ერთი გადასვლით მაინც. ეს გადასვლა ირიბად გულისხმობს, რომ შეყვანის მოქმედება უკვე დასრულებულია. მოქმედების მდგომარეობას არ შეიძლება ჰქონდეს შიდა გადასვლები, რადგან ის ელემენტარულია. მოქმედების მდგომარეობის საერთო გამოყენებაა ალგორითმის (პროცედურის) ან კონტროლის ნაკადის შესრულების ერთი ნაბიჯის მოდელირება.

თანმიმდევრობის დიაგრამა

        მდგომარეობისა და აქტივობის დიაგრამების განხილვისას აღინიშნა, რომ მიუხედავად იმისა, რომ ეს დიაგრამები გამოიყენება სისტემის ქცევის დინამიკის დასაზუსტებლად, მათში დრო აშკარად არ არის წარმოდგენილი. ქცევის დროითი ასპექტი შეიძლება იყოს მნიშვნელოვანი სინქრონული პროცესების მოდელირებისას, რომლებიც აღწერს ობიექტების ურთიერთქმედებას. დროთა განმავლობაში ობიექტების ურთიერთქმედების მოდელირებისთვის, UML იყენებს მიმდევრობის დიაგრამებს.

        მხოლოდ ის ობიექტები, რომლებიც უშუალოდ მონაწილეობენ ურთიერთქმედებაში. მიმდევრობის დიაგრამების გასაღები არის დინამიკა, თუ როგორ ურთიერთქმედებენ ობიექტები დროთა განმავლობაში.

        UML-ში მიმდევრობის დიაგრამას აქვს ორი განზომილება. პირველი არის მარცხნიდან მარჯვნივ ვერტიკალური ხაზების სახით, რომელთაგან თითოეული ასახავს ურთიერთქმედებაში მონაწილე ცალკეული ობიექტის სიცოცხლის ხაზს. სქემის მარცხნივ მდებარე ობიექტი არის ის, რომელიც იწყებს ურთიერთქმედებას. მარჯვნივ არის კიდევ ერთი ობიექტი, რომელიც პირდაპირ ურთიერთქმედებს პირველთან. ამრიგად, მიმდევრობის დიაგრამაში ყველა ობიექტი ქმნის გარკვეულ წესრიგს, რომელიც განისაზღვრება ობიექტების მოქმედების რიგით ან ხარისხით ერთმანეთთან ურთიერთობისას.

        გრაფიკულად, თითოეული ობიექტი გამოსახულია მართკუთხედის სახით და მდებარეობს მისი სიცოცხლის ხაზის ზედა ნაწილში. მართკუთხედის შიგნით ჩაწერეთ ობიექტის სახელი და კლასის სახელი, გამოყოფილი ორწერტილით. ამ შემთხვევაში ხაზგასმულია მთელი ჩანაწერი, რაც ობიექტის ნიშანია.

        მიმდევრობის დიაგრამის მეორე განზომილება არის დროის ვერტიკალური ღერძი, მიმართული ზემოდან ქვემოდან. დიაგრამის ზედა ნაწილი შეესაბამება დროის საწყის მომენტს. ობიექტების ურთიერთქმედება ხორციელდება ერთი ობიექტის მიერ მეორეზე გაგზავნილი შეტყობინებების საშუალებით. შეტყობინებები გამოსახულია ჰორიზონტალური ისრების სახით შეტყობინების სახელით და მათი თანმიმდევრობა განისაზღვრება გაჩენის დროით. ანუ, მიმდევრობის დიაგრამაზე მაღლა მდებარე შეტყობინებები ინიცირებულია ქვედა მდებარეებზე ადრე. მასშტაბი დროის ღერძზე არ არის მითითებული, ვინაიდან თანმიმდევრობის დიაგრამა აყალიბებს მხოლოდ „ადრე-გვიან“ ურთიერთქმედებების დროებით დალაგებას.

თანამშრომლობის დიაგრამა

        თანამშრომლობის დიაგრამის მთავარი მახასიათებელია არა მხოლოდ ურთიერთქმედების თანმიმდევრობის, არამედ ამ ურთიერთქმედების მონაწილე ობიექტებს შორის ყველა სტრუქტურული ურთიერთობის გრაფიკული წარმოდგენის შესაძლებლობა.

სურათი - 3. თანამშრომლობის დიაგრამა

        ამ ტიპის დიაგრამა საშუალებას გაძლევთ აღწეროთ ობიექტების ურთიერთქმედება, აბსტრაქტირება შეტყობინების გადაცემის თანმიმდევრობიდან. ამ ტიპის დიაგრამა კომპაქტურად აჩვენებს კონკრეტული ობიექტის ყველა მიღებულ და გადაცემულ შეტყობინებას და ამ შეტყობინებების ტიპებს.

        უპირველეს ყოვლისა, თანამშრომლობის დიაგრამა ასახავს ურთიერთქმედებაში მონაწილე ობიექტებს მართკუთხედების სახით, რომლებიც შეიცავს ობიექტის სახელს, მის კლასს და, შესაძლოა, ატრიბუტების მნიშვნელობებს. გარდა ამისა, როგორც კლასის დიაგრამაში, ობიექტებს შორის ასოციაციები მითითებულია სხვადასხვა დამაკავშირებელი ხაზების სახით. ამ შემთხვევაში, თქვენ შეგიძლიათ პირდაპირ მიუთითოთ ასოციაციის სახელები და როლები, რომლებსაც ობიექტები ასრულებენ ამ ასოციაციაში. გარდა ამისა, დინამიური კავშირები - შეტყობინებების ნაკადები - შეიძლება იყოს გამოსახული. ისინი ასევე წარმოდგენილია როგორც დამაკავშირებელი ხაზები ობიექტებს შორის, რომელთა ზემოთ არის ისარი, რომელიც მიუთითებს მიმართულებას, შეტყობინების სახელსა და მიმდევრობის ნომერს შეტყობინების ინიციალიზაციის ზოგადი თანმიმდევრობით.

        მიმდევრობის დიაგრამისგან განსხვავებით, თანამშრომლობის დიაგრამა ასახავს მხოლოდ ურთიერთობებს ობიექტებს შორის, რომლებიც ასრულებენ კონკრეტულ როლებს ურთიერთქმედებაში. ეს სქემა არ აჩვენებს დროს, როგორც ცალკე განზომილებას. ამრიგად, ურთიერთქმედებებისა და პარალელური ნაკადების თანმიმდევრობა შეიძლება განისაზღვროს მიმდევრობითი ნომრების გამოყენებით. ამიტომ, თუ თქვენ გჭირდებათ ობიექტებს შორის ურთიერთობების პირდაპირ დაზუსტება რეალურ დროში, უმჯობესია ამის გაკეთება მიმდევრობით დიაგრამაში.

        კონცეფცია თანამშრომლობაარის UML ენის ერთ-ერთი ფუნდამენტური ცნება. ის ემსახურება ობიექტების ნაკრების განსაზღვრას, რომლებიც ურთიერთქმედებენ კონკრეტულ მიზანთან მოდელირებული სისტემის ზოგად კონტექსტში. თავად თანამშრომლობის მიზანია სისტემაში ცალკეული ყველაზე მნიშვნელოვანი ოპერაციების განხორციელების მახასიათებლების დაზუსტება. თანამშრომლობა განსაზღვრავს სისტემის ქცევის სტრუქტურას ამ თანამშრომლობის მონაწილეთა ურთიერთქმედების თვალსაზრისით.

        თანამშრომლობა შეიძლება წარმოდგენილი იყოს ორ დონეზე:

• სპეციფიკაციის დონე - აჩვენებს კლასიფიკატორების როლებს და ასოციაციების როლებს განსახილველ ურთიერთქმედებაში;
• მაგალითის დონე - მიუთითებს შემთხვევებსა და ურთიერთობებზე, რომლებიც ქმნიან ინდივიდუალურ როლებს თანამშრომლობაში.

        სპეციფიკაციის დონის თანამშრომლობის დიაგრამა გვიჩვენებს როლებს, რომლებიც ასრულებენ ურთიერთქმედებაში ჩართულ ელემენტებს. ამ დონეზე თანამშრომლობის ელემენტებია კლასები და ასოციაციები, რომლებიც აღნიშნავენ კლასიფიკატორების ინდივიდუალურ როლებს და ასოციაციებს თანამშრომლობის მონაწილეებს შორის.

        მაგალითის დონის თანამშრომლობის დიაგრამა წარმოდგენილია ობიექტების (კლასების ეგზემპლარები) და კავშირების (ასოციაციების შემთხვევები) სიმრავლით. ამ შემთხვევაში, კავშირები დამატებულია შეტყობინების ისრებით. ამ დონეზე ნაჩვენებია მხოლოდ ობიექტები, რომლებიც პირდაპირ კავშირშია ოპერაციის ან კლასიფიკატორის განხორციელებასთან. ამ შემთხვევაში, საერთოდ არ არის აუცილებელი ყველა თვისების ან ყველა ასოციაციის გამოსახვა, რადგან თანამშრომლობის დიაგრამა შეიცავს მხოლოდ კლასიფიკატორების როლებს, მაგრამ არა თავად კლასიფიკატორებს. ამრიგად, მაშინ, როდესაც კლასიფიკატორი მოითხოვს მისი ყველა შემთხვევის სრულ აღწერას, კლასიფიკატორის როლი მოითხოვს მხოლოდ იმ თვისებებისა და ასოციაციების აღწერას, რომლებიც აუცილებელია კონკრეტულ თანამშრომლობაში მონაწილეობისთვის.

        აქედან გამომდინარეობს მნიშვნელოვანი შედეგი. ობიექტების ერთსა და იმავე კომპლექტს შეუძლია მონაწილეობა მიიღოს სხვადასხვა თანამშრომლობაში. განხილული თანამშრომლობიდან გამომდინარე, ინდივიდუალური ობიექტების თვისებები და მათ შორის კავშირები შეიძლება შეიცვალოს. ეს არის ის, რაც განასხვავებს თანამშრომლობის დიაგრამას კლასის დიაგრამასგან, რომელიც უნდა მიუთითებდეს დიაგრამის ელემენტებს შორის ყველა თვისებასა და ასოციაციებს.

კომპონენტის დიაგრამა

        ამ ტიპის დიაგრამა მიზნად ისახავს კლასების და ობიექტების განაწილებას კომპონენტებს შორის სისტემის ფიზიკური დიზაინის დროს. ამ ტიპის დიაგრამას ხშირად უწოდებენ მოდულის დიაგრამებს.

სურათი - 4. კომპონენტის დიაგრამა

        სრული პროგრამული სისტემის დიზაინი არის ლოგიკური და ფიზიკური დონის მოდელების ნაკრები, რომლებიც უნდა შეესაბამებოდეს ერთმანეთს. UML იყენებს განხორციელების დიაგრამებს სისტემის მოდელების ფიზიკურად წარმოსადგენად, რომელიც მოიცავს კომპონენტის დიაგრამადა განლაგების დიაგრამა.

        კომპონენტის დიაგრამა, ადრე განხილული დიაგრამებისგან განსხვავებით, აღწერს სისტემის ფიზიკური წარმოდგენის მახასიათებლებს. ის საშუალებას გაძლევთ განსაზღვროთ შემუშავებული სისტემის არქიტექტურა პროგრამული უზრუნველყოფის კომპონენტებს შორის დამოკიდებულების დადგენით, რაც შეიძლება იყოს წყარო და შესრულებადი კოდი. კომპონენტის დიაგრამის ძირითადი გრაფიკული ელემენტებია კომპონენტები, ინტერფეისები და მათ შორის დამოკიდებულებები.

        კომპონენტის დიაგრამა შემუშავებულია შემდეგი მიზნებისთვის:

• პროგრამული სისტემის საწყისი კოდის ზოგადი სტრუქტურის ვიზუალიზაცია;
• პროგრამული სისტემის შესრულებადი ვერსიის სპეციფიკაციები;
• ინდივიდუალური პროგრამის კოდის ფრაგმენტების ხელახალი გამოყენების უზრუნველყოფა;
• კონცეპტუალური და ფიზიკური მონაცემთა ბაზის სქემების წარმოდგენები.

        კომპონენტების დიაგრამების შემუშავებაში მონაწილეობენ როგორც სისტემის ანალიტიკოსები, ასევე არქიტექტორები, ასევე პროგრამისტები. კომპონენტის დიაგრამა უზრუნველყოფს თანმიმდევრულ გადასვლას ლოგიკური წარმოდგენიდან პროექტის კონკრეტულ განხორციელებაზე პროგრამული კოდის სახით. ზოგიერთი კომპონენტი შეიძლება არსებობდეს მხოლოდ პროგრამის კოდის შედგენის ეტაპზე, ზოგი კი მისი შესრულების ეტაპზე. კომპონენტის დიაგრამა ასახავს ზოგად დამოკიდებულებებს კომპონენტებს შორის, განიხილავს ამ უკანასკნელს, როგორც კლასიფიკატორს.

        ფიზიკური პირების წარმოსაჩენად UML ენაზე გამოიყენება სპეციალური ტერმინი - კომპონენტი. კომპონენტი ახორციელებს ინტერფეისების გარკვეულ კომპლექტს და ემსახურება ზოგადად მოდელის ფიზიკური წარმოდგენის ელემენტების განსაზღვრას. კომპონენტის გრაფიკულად წარმოსადგენად გამოიყენება სპეციალური სიმბოლო - მართკუთხედი მარცხნივ ჩასმული ორი პატარა ოთხკუთხედით. დიდი მართკუთხედის შიგნით არის კომპონენტის სახელი და, საჭიროების შემთხვევაში, დამატებითი ინფორმაცია. ამ სიმბოლოს გარეგნობა შეიძლება ოდნავ განსხვავდებოდეს კომპონენტთან დაკავშირებული ინფორმაციის ბუნების მიხედვით.

განლაგების დიაგრამა

        ამ ტიპის დიაგრამა განკუთვნილია სისტემის აპარატურის, ანუ აპარატურის და არა პროგრამების გასაანალიზებლად. ინგლისურიდან პირდაპირ თარგმნილი Deployment ნიშნავს "განლაგებას", მაგრამ ტერმინი "ტოპოლოგია" უფრო ზუსტად ასახავს ამ ტიპის დიაგრამის არსს.

სურათი - 5. განლაგების დიაგრამა

        პროგრამული სისტემის ფიზიკური წარმოდგენა არ შეიძლება იყოს სრული, თუ არ არის ინფორმაცია, თუ რა პლატფორმაზე და რა გამოთვლით საშუალებებით არის ის დანერგილი. თუ შემუშავებულია პროგრამა, რომელიც მუშაობს ლოკალურად მომხმარებლის კომპიუტერზე და არ იყენებს პერიფერიულ მოწყობილობებსა და რესურსებს, მაშინ არ არის საჭირო დამატებითი დიაგრამების შემუშავება. კორპორატიული აპლიკაციების შემუშავებისას, ასეთი დიაგრამების არსებობა შეიძლება ძალიან სასარგებლო იყოს კომპონენტების რაციონალური განლაგების პრობლემების გადასაჭრელად, რათა ეფექტურად გამოიყენონ ქსელის განაწილებული გამოთვლითი და საკომუნიკაციო რესურსები, უსაფრთხოების უზრუნველყოფა და სხვა.

        განლაგების დიაგრამები გამოიყენება UML-ში განაწილებული პროგრამული სისტემის ზოგადი კონფიგურაციისა და ტოპოლოგიის წარმოსაჩენად.

        განლაგების დიაგრამა შექმნილია პროგრამის ელემენტებისა და კომპონენტების ვიზუალიზაციისთვის, რომლებიც არსებობს მხოლოდ გაშვების ეტაპზე. ამ შემთხვევაში წარმოდგენილია მხოლოდ პროგრამის ინსტანციის კომპონენტები, რომლებიც არის შესრულებადი ფაილები ან დინამიური ბიბლიოთეკები. ის კომპონენტები, რომლებიც არ გამოიყენება მუშაობის დროს, არ არის ნაჩვენები განლაგების დიაგრამაში. ამრიგად, კომპონენტები პროგრამის წყაროს კოდებით შეიძლება იყოს წარმოდგენილი მხოლოდ კომპონენტის დიაგრამაზე. ისინი არ არის მითითებული განლაგების დიაგრამაზე.

        განლაგების დიაგრამა შეიცავს პროცესორების, მოწყობილობების, პროცესების და მათ შორის კავშირების გრაფიკულ გამოსახულებებს. ლოგიკური წარმოდგენის დიაგრამებისგან განსხვავებით, განლაგების დიაგრამა მთლიანი სისტემისთვის ერთგვაროვანია, რადგან ის სრულად უნდა ასახავდეს მისი განხორციელების მახასიათებლებს. განლაგების დიაგრამის შემუშავება, როგორც წესი, ბოლო ნაბიჯია პროგრამული სისტემის მოდელის განსაზღვრაში.

        განლაგების დიაგრამის შემუშავებისას მიიღწევა შემდეგი მიზნები:

• განსაზღვროს სისტემის კომპონენტების განაწილება მის ფიზიკურ კვანძებში;
• სისტემის დანერგვის ყველა კვანძს შორის ფიზიკური კავშირების ჩვენება მისი შესრულების ეტაპზე;
• სისტემის შეფერხებების იდენტიფიცირება და მისი ტოპოლოგიის ხელახლა კონფიგურაცია საჭირო შესრულების მისაღწევად.

        განლაგების დიაგრამები შემუშავებულია ერთობლივად სისტემის ანალიტიკოსების, ქსელის ინჟინრებისა და სისტემების ტექნიკოსების მიერ.

Rational Rose სამუშაო ინტერფეისის მახასიათებლები

        Rational Rose CASE ინსტრუმენტი ახორციელებს ზოგადად მიღებულ სტანდარტებს პროგრამის ოპერაციული ინტერფეისისთვის, კარგად ცნობილი ვიზუალური პროგრამირების გარემოს მსგავსი. მომხმარებლის კომპიუტერზე Rational Rose-ის დაყენების შემდეგ, რაც პრაქტიკულად არ უქმნის სირთულეებს დამწყებთათვისაც კი, ამ პროგრამის გაშვება MS Windows 95/98-ში იწვევს სამუშაო ინტერფეისის გამოჩენას ეკრანზე (ნახ. 6).

სურათი - 6.რაციონალური ვარდების პროგრამის სამუშაო ინტერფეისის ზოგადი ხედი

        რაციონალური ვარდების ოპერაციული ინტერფეისი შედგება სხვადასხვა ელემენტისგან, რომელთაგან მთავარია:

• პროგრამის მთავარი მენიუ
• დიაგრამის ფანჯარა
• დოკუმენტაციის ფანჯარა
• ბრაუზერის ფანჯარა
• ჟურნალის ფანჯარა

მოდით მოკლედ განვიხილოთ თითოეული ამ ელემენტის მიზანი და ძირითადი ფუნქციები.

პროგრამის მთავარი მენიუ

პროგრამის მთავარი მენიუ შედგენილია ზოგადად მიღებული სტანდარტით და ასე გამოიყურება (ნახ. 7).

მენიუს ცალკეული ელემენტები, რომელთა დანიშნულება აშკარაა მათი სახელებიდან, აერთიანებს მსგავს ოპერაციებს, რომლებიც დაკავშირებულია მთლიან პროექტთან მთლიანობაში. მენიუს ზოგიერთი ელემენტი შეიცავს ცნობილ ფუნქციებს (პროექტის გახსნა, დიაგრამების დაბეჭდვა, სქემის სხვადასხვა ელემენტების კოპირება და ჩასმა ბუფერიდან). სხვები იმდენად სპეციფიკურია, რომ შესაძლოა დამატებითი ძალისხმევა დასჭირდეს შესასწავლად (კოდის გენერირების ვარიანტები, მოდელის თანმიმდევრულობის შემოწმება, დამატებითი მოდულების დაკავშირება).

სურათი - 7.პროგრამის მთავარი მენიუს გამოჩენა

სტანდარტული ხელსაწყოთა პანელი

სტანდარტული ინსტრუმენტთა პანელი განლაგებულია პროგრამის მთავარი მენიუს ქვემოთ და ასე გამოიყურება (სურ. 8). ზოგიერთი ინსტრუმენტი მიუწვდომელია (ახალ პროექტს არ აქვს რაიმე ელემენტი). სტანდარტული ხელსაწყოთა პანელი უზრუნველყოფს სწრაფ წვდომას მენიუს ბრძანებებზე, რომლებსაც დეველოპერები ყველაზე ხშირად იყენებენ.

Ფიგურა 8.სტანდარტული ხელსაწყოთა ზოლის გამოჩენა

მომხმარებელს შეუძლია ამ პანელის გარეგნობის მორგება საკუთარი შეხედულებისამებრ. ამისათვის აირჩიეთ მენიუს პუნქტი Tools -> Options და გახსენით Toolbars ჩანართი. ამ გზით თქვენ შეგიძლიათ აჩვენოთ ან დამალოთ სხვადასხვა ხელსაწყოს ღილაკები და შეცვალოთ მათი ზომა.

ბრაუზერის ფანჯარა

ბრაუზერის ნაგულისხმევი ფანჯარა მდებარეობს სამუშაო ინტერფეისის მარცხენა მხარეს სტანდარტული ხელსაწყოთა ზოლის ქვეშ (ნახ. 9).

ბრაუზერი აწყობს მოდელის ხედებს იერარქიულ სტრუქტურაში, რაც ამარტივებს ნავიგაციას და საშუალებას გაძლევთ იპოვოთ ნებისმიერი მოდელის ელემენტი პროექტში. ამ შემთხვევაში, ნებისმიერი ელემენტი, რომელსაც დეველოპერი დაამატებს მოდელს, დაუყოვნებლივ გამოჩნდება ბრაუზერის ფანჯარაში. შესაბამისად, ბრაუზერის ფანჯარაში ელემენტის არჩევით შეგვიძლია მისი ვიზუალიზაცია დიაგრამის ფანჯარაში ან შევცვალოთ მისი სპეციფიკაცია. ბრაუზერი ასევე საშუალებას გაძლევთ მოაწყოთ მოდელის ელემენტები პაკეტებში და გადაიტანოთ ელემენტები მოდელის სხვადასხვა ხედებს შორის. თუ სასურველია, ბრაუზერის ფანჯარა შეიძლება განთავსდეს სხვა ადგილას სამუშაო ინტერფეისში ან საერთოდ დამალული იყოს მენიუს პუნქტის View გამოყენებით. თქვენ ასევე შეგიძლიათ შეცვალოთ ბრაუზერის ზომა მისი გარე ჩარჩოს მაუსის გადატანით.

სურათი - 9.ბრაუზერის გარეგნობა

სპეციალური ხელსაწყოთა პანელი

სპეციალური ხელსაწყოთა პანელი განთავსებულია ბრაუზერის ფანჯარასა და დიაგრამის ფანჯარას შორის სამუშაო ინტერფეისის შუა ნაწილში. ნაგულისხმევად, ინსტრუმენტთა პანელი შემოთავაზებულია მოდელის კლასის დიაგრამის ასაგებად (ნახ. 10).

სურათი - 10.კლასის დიაგრამისთვის სპეციალური ხელსაწყოთა ზოლის გამოჩენა

სპეციალური ხელსაწყოთა ზოლის მდებარეობა შეიძლება შეიცვალოს პანელის ჩარჩოს სასურველ ადგილას გადატანით. თქვენ ასევე შეგიძლიათ დააკონფიგურიროთ პანელის შემადგენლობა გარკვეული ინსტრუმენტების შესაბამისი ცალკეული ღილაკების დამატებით ან ამოღებით. ღილაკების დავალებების სწავლა შესაძლებელია ინსტრუმენტების რჩევებიდან, რომლებიც გამოჩნდება მას შემდეგ, რაც მაუსის ინდიკატორი გადაადგილდება შესაბამის ღილაკზე.

დიაგრამის ფანჯარა

დიაგრამის ფანჯარა არის მისი ინტერფეისის ძირითადი სამუშაო არე, რომელშიც ვიზუალიზაციაა პროექტის მოდელის სხვადასხვა ხედები. ნაგულისხმევად, დიაგრამის ფანჯარა მდებარეობს სამუშაო ინტერფეისის მარჯვენა მხარეს, მაგრამ მისი მდებარეობა და ზომა ასევე შეიძლება შეიცვალოს. ახალი პროექტის შემუშავებისას, თუ Project Wizard არ არის გამოყენებული, დიაგრამის ფანჯარა არის ცარიელი ადგილი, რომელიც არ შეიცავს მოდელის ელემენტებს (ნახ. 11).

დიაგრამის სახელი, რომელიც მდებარეობს ამ ფანჯარაში, მითითებულია პროგრამის სათაურის ზოლში (პროგრამის ყველაზე მაღალი ხაზი) ​​ან, თუ ფანჯარა არ არის მაქსიმიზებული სრულ ეკრანზე, დიაგრამის ფანჯრის სათაურის ზოლში. სქემის ფანჯარაში ერთდროულად შეიძლება იყოს რამდენიმე დიაგრამა, მაგრამ მათგან მხოლოდ ერთი შეიძლება იყოს აქტიური. მაგალითად, ნახ. 11 აქტიური დიაგრამა არის განლაგების დიაგრამა, თუმცა არის სხვა დიაგრამები. დიაგრამებს შორის გადართვა შეიძლება განხორციელდეს სასურველი ხედის არჩევით სტანდარტულ ინსტრუმენტთა პანელზე ან Window მენიუს ელემენტის მეშვეობით. ცალკე დიაგრამის ხედის გააქტიურებისას, იცვლება სპეციალური ხელსაწყოთა ზოლის გამოჩენა, რომელიც მორგებულია კონკრეტული დიაგრამის ხედისთვის.

სურათი - 11.დიაგრამის ფანჯრის გამოჩენა სხვადასხვა ტიპის მოდელის ხედებით

დოკუმენტაციის ფანჯარა

დოკუმენტაციის ფანჯარა შეიძლება არ იყოს ეკრანზე ნაგულისხმევად. ამ შემთხვევაში მისი გააქტიურება შესაძლებელია მენიუს პუნქტის View -> Documentation მეშვეობით, რის შემდეგაც გამოჩნდება ბრაუზერის ქვემოთ (სურ. 12).

დოკუმენტაციის ფანჯარა, როგორც მისი სახელი გვთავაზობს, შექმნილია მოდელის ხედის ელემენტების დოკუმენტაციისთვის. მასში შეგიძლიათ ჩაწეროთ მრავალფეროვანი ინფორმაცია და რაც მნიშვნელოვანია - რუსულ ენაზე. ეს ინფორმაცია შემდგომში გარდაიქმნება კომენტარებად და არანაირად არ მოქმედებს პროგრამის კოდის შესრულების ლოგიკაზე.

დოკუმენტაციის ფანჯარაში გააქტიურებულია ინფორმაცია, რომელიც ეხება დიაგრამის ცალკეულ შერჩეულ ელემენტს. ამ შემთხვევაში, თქვენ შეგიძლიათ აირჩიოთ ელემენტი ბრაუზერის ფანჯარაში ან დიაგრამის ფანჯარაში. დიაგრამაზე ახალ ელემენტს (მაგალითად, კლასს) დაამატებთ, ავტომატურად იქმნება დოკუმენტაცია, რომელიც ცარიელია (დოკუმენტაციის გარეშე). შემდგომში, დეველოპერი დამოუკიდებლად შეაქვს საჭირო განმარტებით ინფორმაციას, რომელიც ახსოვს და შეიძლება შეიცვალოს პროექტზე მუშაობის დროს.

ისევე, როგორც სამუშაო ინტერფეისის სხვა ფანჯრებისთვის, შეგიძლიათ შეცვალოთ დოკუმენტაციის ფანჯრის ზომა და პოზიცია.

სურათი - 12.დოკუმენტაციის ფანჯრის გამოჩენა

ჟურნალის ფანჯარა

ჟურნალის ფანჯარა შექმნილია იმისათვის, რომ ავტომატურად ჩაიწეროს სხვადასხვა სერვისის ინფორმაცია, რომელიც გენერირებულია პროგრამასთან მუშაობისას. ჟურნალი აღრიცხავს დეველოპერის მიერ შესრულებული მოქმედებების დროსა და ბუნებას, როგორიცაა მოდელის განახლება, მენიუების და ხელსაწყოების ზოლების მორგება, ასევე შეცდომის შეტყობინებები, რომლებიც წარმოიქმნება პროგრამის კოდის გენერირებისას.

ჟურნალის ფანჯარა ყოველთვის არის სამუშაო ინტერფეისზე დიაგრამის ფანჯრის არეში (ნახ. 13). თუმცა, ის შეიძლება დამალული იყოს დიაგრამის სხვა ფანჯრებით ან მინიმუმამდე დაყვანილი. ჟურნალის ფანჯრის გააქტიურება შეგიძლიათ Window->Log მენიუს მეშვეობით. ამ შემთხვევაში, იგი ნაჩვენებია სხვა ფანჯრების თავზე სამუშაო ინტერფეისის მარჯვენა ზონაში. ამ ფანჯრის მთლიანად ამოღება შეუძლებელია, მხოლოდ მისი მინიმიზაციაა შესაძლებელი.

სურათი - 13.ჟურნალის ფანჯრის გამოჩენა

დასკვნა

        დროთა განმავლობაში UML ენა გახდება "ესპერანტო", რომელშიც მათემატიკოსები, სისტემური ანალიტიკოსები, ფიზიკოსები, პროგრამისტები, მენეჯერები, ეკონომისტები და სხვა პროფესიის სპეციალისტები შეძლებენ კომუნიკაციას, წარმოადგინონ თავიანთი პროფესიული ცოდნა ერთიანი ფორმით. ყოველივე ამის შემდეგ, არსებითად, თითოეული სპეციალისტი მუშაობს მოდელის წარმომადგენლობით თავის ცოდნის სფეროში. და სწორედ ამ მოდელის ასპექტი შეიძლება დაზუსტდეს UML ენის გამოყენებით.

        ამ მხრივ, UML ენის მნიშვნელობა მნიშვნელოვნად იზრდება, რადგან ის სულ უფრო იძენს ცოდნის წარმომადგენლობითი ენის მახასიათებლებს. ამავდროულად, მოდელის სტრუქტურისა და ქცევის წარმოსადგენად ვიზუალური საშუალებების UML ენაზე არსებობა შესაძლებელს ხდის დეკლარაციული და პროცედურული ცოდნის ადეკვატური წარმოდგენის მიღწევას და, არანაკლებ მნიშვნელოვანია, დაამყაროს სემანტიკური შესაბამისობა ამ ფორმებს შორის. ცოდნა. UML ენის ყველა ეს მახასიათებელი საშუალებას გვაძლევს დავასკვნათ, რომ მას ყველაზე სერიოზული პერსპექტივები აქვს უახლოეს მომავალში.

ეს სტატია იკვლევს პროგრამული უზრუნველყოფის განვითარების ახალ ეპოქას, თუ როგორ აისახება იგი UML-ის ახალ მოთხოვნებზე და მათ დაკმაყოფილების საუკეთესო პრაქტიკაზე.
  7. „მონაცემთა მოდელირება რაციონალურ ვარდში“ სერგეი ტროფიმოვი აღწერს მონაცემთა ფიზიკური წარმოდგენის მოდელირებას რაციონალური ვარდის გამოყენებით
  8. UML ენა. UML ენის ზოგადი გაგება: ენის სტრუქტურები, გრაფიკული ელემენტები და დიაგრამები.
  9. პრაქტიკული UML. ეს დოკუმენტი არის დოკუმენტის "პრაქტიკული UML. პრაქტიკული შესავალი დეველოპერებისთვის" თარგმანი. პრაქტიკული შესავალი დეველოპერებისთვის
  10. "სტანდარტული ობიექტზე ორიენტირებული მოდელირების ენა UML" ვენდროვი ალექსანდრე მიხაილოვიჩი. UML-ის ისტორია
  11. UML – ერთიანი მოდელირების ენა. ეს მასალა შეიცავს საწყის ინფორმაციას UML-ში გამოყენებული პროგრამული სისტემებისა და აღნიშვნების აღწერის მეთოდების შესახებ
  12. UML ენა. Მომხმარებლის სახელმძღვანელო. ავტორები: გრეიდი ბუჩი, ჯეიმს რუმბო, ივარ ჯეიკობსონი
  13. "UML დიაგრამები რაციონალურ ვარდში" სერგეი ტროფიმოვი
  14. "ანალიზი და დიზაინი. ვიზუალური მოდელირება (UML) რაციონალური ვარდი" კონსტანტინე დომოლეგო
  15. გენადი ვერნიკოვის ბიბლიოთეკა. დიზაინისა და მოდელირების სტანდარტების სრული აღწერა.
  16. „პროგრამული სისტემების შემუშავებისას UML-ის გამოყენებით საგნის არეალის აღწერის მაგალითი“ E.B. ზოლოთუხინა, რ.ვ. ალფიმოვი. სტატია იყენებს კონკრეტულ მაგალითს დომენის მოდელირების შესაძლო მიდგომის დემონსტრირებისთვის ერთიანი მოდელირების ენის (UML) გამოყენების საფუძველზე.