uml დიაგრამების დანიშნულება. UML დიაგრამა

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

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

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

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

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

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

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

UML დიაგრამები

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ზოგადი UML მექანიზმები

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

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

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

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

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

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

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

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

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

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

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

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

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

ნახაზი - 1. გამოყენების ქეისის დიაგრამა

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

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

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

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

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

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

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

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

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

ნახაზი - 2. კლასის დიაგრამა

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

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

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

მდგომარეობის დიაგრამა (statechart დიაგრამა)

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

        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 (Tools -> Options) და გახსენით ჩანართი Toolbars (Toolbars). ამ გზით თქვენ შეგიძლიათ აჩვენოთ ან დამალოთ სხვადასხვა ხელსაწყოს ღილაკები, ასევე შეცვალოთ მათი ზომა.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

დასკვნა

       . პროფესიული ცოდნაერთიანი გზით. მართლაც, არსებითად, თითოეული სპეციალისტი მუშაობს მოდელის წარმომადგენლობით თავის ცოდნის სფეროში. და სწორედ ამ მოდელის ასპექტი შეიძლება დაზუსტდეს 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-ის გამოყენებით პროგრამული სისტემების შემუშავებაში" ე.ბ. ზოლოთუხინა, რ.ვ. ალფიმოვი. სტატიაში კონკრეტული მაგალითიაჩვენებს დომენის მოდელირების შესაძლო მიდგომას ერთიანი მოდელირების ენის (UML) გამოყენებაზე დაყრდნობით.

       

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

UML-ის მოკლე ისტორია

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

ობიექტის მართვის ჯგუფის (OMG) მოთხოვნით - ორგანიზაცია, რომელიც პასუხისმგებელია ობიექტის ტექნოლოგიებისა და მონაცემთა ბაზების სფეროში სტანდარტების მიღებაზე, გაერთიანებისა და სტანდარტიზაციის გადაუდებელი პრობლემა გადაჭრეს სამი ყველაზე პოპულარული OO მეთოდის ავტორებმა - G. Booch. , დ. რემბო და ა. ჯეიკობსონმა, რომლებმაც ერთობლივი ძალისხმევით შექმნეს UML ვერსია 1.1, დამტკიცებული OMG-ის მიერ 1997 წელს, როგორც სტანდარტი.

UML არის ენა

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

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

UML ლექსიკა

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

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

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

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

დიაგრამები. UML გთავაზობთ შემდეგ დიაგრამებს:

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

მოდელის კონტროლის ხედი. პაკეტები.

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

რასაც UML გთავაზობთ.

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

და ბოლო…

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

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

რა არის UML?

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

როგორც ვიკიპედია ამბობს

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

ყველაზე საინტერესო, რაზეც ყველა არ ფიქრობს ან გამოცნობს არის ის, რომ UML-ს აქვს სპეციფიკაციები. უფრო მეტიც, არსებობს UML2 სპეციფიკაციაც კი. დამატებითი ინფორმაცია სპეციფიკაციის შესახებ შეგიძლიათ იხილოთ Object Management Group ვებსაიტზე. სინამდვილეში, ეს ჯგუფი დაკავებულია UML სპეციფიკაციების შემუშავებით. ასევე საინტერესოა, რომ UML არ შემოიფარგლება მხოლოდ კლასების სტრუქტურის აღწერით. არსებობს მრავალი სახის UML დიაგრამები. UML დიაგრამების ტიპების მოკლე აღწერა შეგიძლიათ ნახოთ იმავე ვიკიპედიაში: UML დიაგრამები ან ტიმურ ბატირშინოვის ვიდეოში. UML დიაგრამების მიმოხილვა. UML ასევე ფართოდ გამოიყენება სხვადასხვა პროცესების აღწერისას, მაგალითად აქ: ერთჯერადი შესვლა JWT-ის გამოყენებით. UML კლასის დიაგრამების გამოყენებას რომ დავუბრუნდეთ, აღსანიშნავია წიგნი Head First: Design Patterns, რომელშიც შაბლონები ილუსტრირებულია იმავე UML დიაგრამებით. გამოდის, რომ UML ნამდვილად გამოიყენება. და გამოდის, რომ მისი გამოყენების ცოდნა და გაგება საკმაოდ სასარგებლო უნარია.

განაცხადი

ვნახოთ, როგორ შეგიძლიათ მუშაობა ამ UML-თან IDE-დან. როგორც IDE, მიიღეთ IntelliJ იდეა . გამოყენების შემთხვევაში IntelliJ Idea Ultimate, მაშინ ჩვენ გვექნება დაინსტალირებული დანამატი "გარეშე" UML მხარდაჭერა". ის საშუალებას გაძლევთ ავტომატურად შექმნათ ლამაზი კლასის დიაგრამები. მაგალითად, Ctrl + N ან მენიუს პუნქტის "Navigate" -> "Class" გადადით კლასში. ArrayList. ახლა, მეშვეობით კონტექსტური მენიუკლასის სახელის მიხედვით აირჩიეთ "დიაგრამა" -> "დიაგრამის ამომხტარის ჩვენება". შედეგად, ჩვენ ვიღებთ მშვენიერ სქემას:

მაგრამ რა მოხდება, თუ გსურს საკუთარი თავის დახატვა და თუნდაც არ არსებობს იდეის საბოლოო ვერსია? თუ ჩვენ ვიყენებთ IntelliJ Idea Community Edition-ს, მაშინ სხვა არჩევანი არ გვაქვს. ამისათვის თქვენ უნდა გესმოდეთ, თუ როგორ მუშაობს ასეთი UML სქემა. ჯერ უნდა დავაყენოთ Graphviz. ეს არის გრაფიკის ვიზუალიზაციის საშუალებების ნაკრები. მას იყენებს დანამატი, რომელსაც ჩვენ გამოვიყენებთ. ინსტალაციის შემდეგ, თქვენ უნდა დაამატოთ დირექტორია ურნადაინსტალირებული დირექტორიადან graphvizგარემოს ცვლადს ბილიკი. ამის შემდეგ IntelliJ Idea-ში მენიუდან აირჩიეთ File -> Settings. "პარამეტრების" ფანჯარაში აირჩიეთ "Plugins" კატეგორია, დააჭირეთ ღილაკს "Browse repositories" და დააინსტალირეთ PlantUML ინტეგრაციის მოდული. რატომ არის ეს ასე კარგი PlantUML? იგი იყენებს გრაფიკის აღწერის ენას სახელწოდებით " წერტილიდა ეს საშუალებას აძლევს მას იყოს უფრო მრავალმხრივი, რადგან მოცემული ენაგამოიყენება არა მხოლოდ PlantUML. უფრო მეტიც, ყველაფერი, რასაც ქვემოთ გავაკეთებთ, შეგვიძლია არა მხოლოდ IDE-ში, არამედ შიგნითაც ონლაინ სერვისი planttext.com. PlantUML მოდულის დაინსტალირების შემდეგ ჩვენ შევძლებთ შევქმნათ UML დიაგრამები "File" -> "New". მოდით შევქმნათ "UML კლასის" დიაგრამა. ამ დროს ავტომატურად წარმოიქმნება შაბლონი მაგალითით. მოდით, წავშალოთ მისი შიგთავსი და შევქმნათ ჩვენი, შეიარაღებული სტატიით Habr-დან: კლასური ურთიერთობები - UML-დან კოდამდე. და იმის გასაგებად, თუ როგორ უნდა გამოვსახოთ ეს ტექსტში, ავიღოთ PlantUML სახელმძღვანელო: plantuml class-diagram . მასში, თავიდანვე, არის ფირფიტა, თუ როგორ უნდა აღწეროთ კავშირები:

თავად კავშირების შესახებ, ჩვენ ჯერ კიდევ შეგვიძლია აქ ვიხილოთ: "ურთიერთობები კლასებს შორის UML-ში. მაგალითები". ამ მასალებზე დაყრდნობით, დავიწყოთ ჩვენი UML დიაგრამის შექმნა. დაამატეთ შემდეგი შინაარსი, რომელიც აღწერს ორ კლასს: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Idea-ში შედეგის სანახავად აირჩიეთ "View" -> " ინსტრუმენტი Windows" -> "PlantUML". ჩვენ უბრალოდ ვიღებთ ორ კვადრატს, რომელიც წარმოადგენს კლასებს. როგორც ვიცით, ორივე კლასი ახორციელებს List ინტერფეისს. ეს ურთიერთობაკლასებს ეწოდება - განხორციელება (რეალიზაცია). ასეთი ურთიერთობის გამოსახატავად გამოიყენება ისარი წერტილოვანი ხაზით. მოდით დავხატოთ იგი: ინტერფეისის სიის სია< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о პაკეტი პირადიელემენტის მასივი: ~ Object elementData ახლა ჩვენ გვინდა ვაჩვენოთ, რომ ArrayList შეიცავს რამდენიმე ობიექტს. ამ შემთხვევაში, კავშირის ტიპი იქნება - აგრეგაცია(აგრეგაცია). აგრეგატი ამ შემთხვევაში არის ArrayList, რადგან ის შეიცავს სხვა ობიექტებს. ჩვენ ვირჩევთ აგრეგაციას, რადგან სიის ობიექტებს შეუძლიათ იცხოვრონ სიის გარეშე: ისინი არ არიან მისი განუყოფელი ნაწილები. მათი სიცოცხლე არ არის მიბმული სიის სიცოცხლესთან. ერთეული ლათინურიდან ითარგმნება როგორც "შეგროვებული", ანუ რაღაცისგან შემდგარი. მაგალითად, ცხოვრებაში არის სატუმბი დანადგარი, რომელიც შედგება ტუმბოსა და ძრავისგან. თავად ერთეული შეიძლება დაიშალა, მისგან რაღაც დატოვოს შემადგენელი ნაწილები. მაგალითად, გაყიდვა ან სხვა ერთეულის ჩასმა. ასე რომ, სიაშია. და ეს გამოიხატება ცარიელი რომბის სახით ერთეულზე და უწყვეტი ხაზით. მოდით ასე ვთქვათ: კლასი Object ( ) ArrayList o- Object ახლა გვინდა ვაჩვენოთ, რომ ArrayList-ისგან განსხვავებით, LinkedList კლასი შეიცავს Node კონტეინერებს, რომლებიც ეხება შენახულ მონაცემებს. ამ შემთხვევაში კვანძები თავად LinkedList-ის ნაწილია და არ შეუძლიათ ცალკე ცხოვრება. Node არ არის უშუალოდ შენახული შინაარსი, მაგრამ შეიცავს მხოლოდ მასზე მითითებას. მაგალითად, როდესაც ჩვენ ვამატებთ მწკრივს LinkedList-ში, ვამატებთ ახალ კვანძს, რომელიც შეიცავს ბმულს ამ მწკრივთან, ასევე ბმულს წინა და მომდევნო კვანძთან. ამ ტიპის კავშირი ე.წ შემადგენლობა(კომპოზიცია). კომპოზიტის საჩვენებლად (ის, რომელიც შედგება ნაწილებისგან), შედგენილია შევსებული რობი, უწყვეტი ხაზი მივყავართ მას. ახლა მოდით დავწეროთ ეს, როგორც ბმულის ტექსტური ჩვენება: class Node ( ) LinkedList * -- Node და ახლა ჩვენ უნდა ვისწავლოთ როგორ გამოვაჩინოთ სხვა მნიშვნელოვანი ტიპის ბმული - დამოკიდებულება(დამოკიდებულების ურთიერთობა). იგი გამოიყენება, როდესაც ერთი კლასი იყენებს მეორეს, ხოლო კლასი არ შეიცავს გამოყენებულ კლასს და არ არის მისი მემკვიდრე. მაგალითად, LinkedList-ს და ArrayList-ს შეუძლიათ შექმნან ListIterator. მოდით გამოვხატოთ ეს წერტილოვანი ისრების სახით: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:

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

ავტომატიზაცია

Იქ არის სხვადასხვა გზები ავტომატური თაობა PlantUML დიაგრამები. მაგალითად, in იდეებიარის SketchIT მოდული, მაგრამ ის მათ სწორად არ ხატავს. მაგალითად, ინტერფეისების განხორციელება არასწორად არის დახატული (გამოსახულია მემკვიდრეობით). ასევე არსებობს ონლაინ მაგალითები იმის შესახებ, თუ როგორ უნდა ჩართოთ ეს თქვენი პროექტის სასიცოცხლო ციკლში. ვთქვათ ამისთვის მეივენიარსებობს მაგალითი, რომელიც იყენებს uml-java-docklet-ს. იმის საჩვენებლად, თუ როგორ არის ეს, ჩვენ გამოვიყენებთ მავენის არქეტიპს სწრაფი შექმნა maven პროექტი. მოდით შევასრულოთ ბრძანება: mvn archetype:generate ფილტრის არჩევის შესახებ ( აირჩიეთ ნომერი ან გამოიყენეთ ფილტრი) დატოვეთ ნაგულისხმევი უბრალოდ Enter დაჭერით. ყოველთვის იქნება" maven-archetype-სწრაფი დაწყება". ვირჩევთ უახლეს ვერსიას. შემდეგ უპასუხეთ კითხვებს და დაასრულეთ პროექტის შექმნა:

ვინაიდან Maven არ არის ამ სტატიის ფოკუსირება, Maven-ის შესახებ თქვენს კითხვებზე პასუხები შეგიძლიათ იხილოთ Maven-ის მომხმარებელთა ცენტრში. გენერირებულ პროექტში გახსენით პროექტის აღწერილობის ფაილი რედაქტირებისთვის, pom.xml. ჩვენ დავაკოპირებთ მასში uml-java-docklet-ის ინსტალაციის აღწერილობის შიგთავსს. აღწერილობაში გამოყენებული არტეფაქტი ვერ მოიძებნა Maven Central საცავში. მაგრამ ეს მუშაობდა ამით: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. ანუ, ამ აღწერაში თქვენ უბრალოდ უნდა შეცვალოთ ჯგუფის IDთან " info.leadinglight" ზე " com.chfourie"და დააყენე ვერსია" 1.0.0 ამის შემდეგ ჩვენ შეგვიძლია შევასრულოთ იმ დირექტორიაში, სადაც ფაილი მდებარეობს pom.xmlეს ბრძანებებია: mvn clean install და mvn javadoc:javadoc . ახლა, თუ ჩვენ გავხსნით გენერირებულ დოკუმენტაციას (explorer target\site\apidocs\index.html), დავინახავთ UML დიაგრამებს. სხვათა შორის, განხორციელება უკვე სწორად არის ნაჩვენები აქ)

დასკვნა

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

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

კომერციული პროდუქტები

Microsoft Visio

ტიპი: კომერციული პროგრამული უზრუნველყოფა

პოპულარული პროგრამული უზრუნველყოფა Microsoft-ისგან, რომელიც საშუალებას გაძლევთ დახაზოთ მდიდარი დიაგრამები, მათ შორის UML:

2010 წლის ვერსიიდან დაწყებული, შესაძლებელი გახდა დიაგრამების გამოქვეყნება ინტერნეტში (SharePoint + Visio Services):

Visio Viewer- უფასო პროგრამა, რომელიც საშუალებას გაძლევთ ნახოთ ადრე შექმნილი Visio დიაგრამები. შეგიძლიათ ჩამოტვირთოთ %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20ექსპრეს%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20მოდელირება,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20მიმდევრობა%20დიაგრამა%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20გამოყენება%20საქმე%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20ვიზუალიზაცია%20და%20მოდელირება%20ფუნქცია%20პაკეტი%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

• %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%0A
• %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20ფენა%20დიაგრამები%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%0A
• %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20ფენა%20დიაგრამები
%0A

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20ვიზუალიზაცია%20და%20მოდელირება%20ფუნქცია%20პაკეტი%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/en-us/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

შესაძლებლობები:

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

ეკრანის ანაბეჭდები:

ღია კოდის პროგრამები

StarUML

შესაძლებლობები:

• UML 2.0 მხარდაჭერა
• MDA (მოდელზე ორიენტირებული არქიტექტურა)
• Plug-in Architecture (შეგიძლიათ დაწეროთ COM თავსებადი ენებზე: C++, Delphi, C#, VB, ...)

StarUML იწერება ძირითადად Delphi-ში, მაგრამ თქვენ შეგიძლიათ დაამატოთ კომპონენტები სხვა ენებზე, როგორიცაა C/C++, Java, Visual Basic, დელფი, JScript, VBScript, C#, VB.NET. ქვემოთ მოცემულია რამდენიმე ეკრანის სურათი.

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

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

ArgoUML

მხარდაჭერილი სქემები:

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

შესაძლებლობები:

• ცხრა UML 1.4 დიაგრამის მხარდაჭერა
• დამოუკიდებელი პლატფორმა (Java 5+)
• UML 1.4 სტანდარტული მეტამოდელი
• XMI მხარდაჭერა
• ექსპორტი GIF, PNG, PS, EPS, PGML და SVG-ში
• ენები: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
• OCL მხარდაჭერა
• Forward, Reverse Engineering

სკრინშოტი:

10.4. UML დიაგრამა

10.4.1. ვიზუალური UML დიაგრამების სახეები

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

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

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

კოოპერატივის სქემები;

კლასის დიაგრამები;

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

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

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

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

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

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

ბრინჯი. 10.1.გამოიყენეთ საქმის დიაგრამა

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

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

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

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

სურათი 10.2.კლიენტი ჯოს $20 თანმიმდევრობის დიაგრამა

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

გამოყენების შემთხვევა იწყება მაშინ, როდესაც კლიენტი ათავსებს თავის ბარათს მკითხველში - ეს ობიექტი ნაჩვენებია დიაგრამის ზედა ველში. ის კითხულობს ბარათის ნომერს, ხსნის Joe ანგარიშის ობიექტს და ახდენს ბანკომატის ეკრანის ინიციალიზებას. ეკრანი ჯოს სთხოვს მის სარეგისტრაციო ნომერს. კლიენტი შეიყვანს ნომერს 1234. ეკრანი ამოწმებს ნომერს Joe ანგარიშის ობიექტზე და აღმოაჩენს, რომ ის სწორია. შემდეგ ეკრანი ჯოს წარუდგენს მენიუს, რომლიდანაც უნდა აირჩიოს და ის ირჩევს "გადაღებას". ეკრანი ეკითხება, რამდენის ამოღება სურს და ჯო შეაქვს $20. ეკრანი იღებს ფულს ანგარიშიდან. ამით ის იწყებს პროცესების სერიას, რომელსაც ასრულებს Joe Account ობიექტი. ამავდროულად, კეთდება შემოწმება, რომ ანგარიშზე არის მინიმუმ 20 დოლარი და საჭირო თანხა ჩამოიჭრება ანგარიშიდან. ამის შემდეგ სალარო აპარატს ევალება „გაანაწილოს ჩეკი და 20 დოლარი ნაღდი ფულით“. საბოლოოდ, იგივე „ჯოს ანგარიში“ ობიექტი ავალებს ბარათის მკითხველს დააბრუნოს ბარათი.

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

10.4.4. co-op ჩარტებში

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

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

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

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

10.4.5. კლასის დიაგრამები

კლასის დიაგრამები ასახავს ურთიერთქმედებას სისტემის კლასებს შორის. მაგალითად, "ჯოს ანგარიში" არის ობიექტი. ასეთი ობიექტის ტიპად შეიძლება ჩაითვალოს ზოგადად ანგარიში, ანუ "ანგარიში" არის კლასი. კლასები შეიცავს მონაცემებს და ქცევებს (მოქმედებებს), რომლებიც გავლენას ახდენენ ამ მონაცემებზე. ამრიგად, Account კლასი შეიცავს კლიენტის საიდენტიფიკაციო ნომერს და მის შემოწმებულ მოქმედებებს. კლასის დიაგრამაში, კლასი იქმნება თითოეული ტიპის ობიექტისთვის Sequence Diagrams ან Co-op Diagrams-დან. კლასის დიაგრამა "ფულის ამოღება" გამოყენების შემთხვევისთვის ნაჩვენებია სურათზე 1. 10.4.

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

ბრინჯი. 10.4.კლასის დიაგრამა

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

10.4.6. სახელმწიფო დიაგრამები

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

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

ბრინჯი. 10.5.მდგომარეობის დიაგრამა Account კლასისთვის

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

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

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

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

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

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

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

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

ნახ. 10.6 გვიჩვენებს ბანკომატის სისტემის ერთ-ერთი კომპონენტის დიაგრამას. ეს დიაგრამა აჩვენებს ბანკომატის სისტემის კლიენტის კომპონენტებს. ამ შემთხვევაში, დეველოპერმა გუნდმა გადაწყვიტა სისტემის აგება C++ ენის გამოყენებით. თითოეულ კლასს აქვს საკუთარი სათაურის ფაილი და გაფართოების ფაილი. CPP ისე, რომ თითოეული კლასი გარდაიქმნება დიაგრამაში თავის კომპონენტებად. შერჩეული მუქი კომპონენტი ე.წ პაკეტის სპეციფიკაციადა შეესაბამება C++ ATM კლასის სხეულის ფაილს (.cpp ფაილი). არჩეულ კომპონენტს ასევე უწოდებენ პაკეტის სპეციფიკაციას, მაგრამ შეესაბამება C++ ენის კლასის სათაურის ფაილს (.h ფაილის გაფართოება). ბანკომატის კომპონენტი. exe არის ამოცანის სპეციფიკაცია და წარმოადგენს ინფორმაციის დამუშავების ნაკადს. ამ შემთხვევაში, დამუშავების თემა არის შესრულებადი პროგრამა.

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

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

ბრინჯი. 10.6.კომპონენტის დიაგრამა

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

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

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

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

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

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

წიგნიდან მაიკროსოფტის ოფისი ავტორი ლეონტიევი ვიტალი პეტროვიჩი

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

წიგნიდან Computer 100. დაწყებული Windows Vista ავტორი ზოზულია იური

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

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

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

Excel-ის სამუშაო წიგნიდან. მულტიმედიური კურსი ავტორი მედინოვი ოლეგი

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

წიგნიდან Word 2007. პოპულარული სახელმძღვანელო ავტორი კრაინსკი ი

სქემის აგება პირველი მაგალითისთვის, თქვენ უნდა შექმნათ ცხრილი, რომელიც ნაჩვენებია ნახ. 8.1. ბრინჯი. 8.1. ტემპერატურის საზომი ცხრილი ამ ცხრილის მონაცემებზე დაყრდნობით ავაშენებთ მარტივ ტემპერატურულ სქემას.1. მონიშნეთ შევსებული დიაპაზონი ცხრილში.2. Წადი

წიგნიდან კომპიუტერული გაკვეთილი ავტორი კოლისნიჩენკო დენის ნიკოლაევიჩი

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

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

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

წიგნიდან პროგრამირების ტექნოლოგიები ავტორი კამაევი ვ ა

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

წიგნიდან Business Process Modeling with BPwin 4.0 ავტორი მაკლაკოვი სერგეი ვლადიმროვიჩი

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

წიგნიდან OrCAD PSpice. ელექტრული წრედის ანალიზი მიერ Keown J.

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

VBA წიგნიდან Dummies-ისთვის ავტორი კამინგს სტივ

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

წიგნიდან Macintosh Tutorial ავტორი სკრილინა სოფია

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

ავტორის წიგნიდან

დროის დიაგრამები შემავალი და გამომავალი ძაბვის დროის დიაგრამების მისაღებად, თქვენ უნდა ოდნავ შეცვალოთ შეყვანის ფაილი. როგორც წინა მაგალითში, გამოყენებული იქნება სინუსოიდური შეყვანის ძაბვა: Vi 1 0 sin (0 0.5V 5kHz) გარდამავალ ანალიზთან ერთად

ავტორის წიგნიდან

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

ავტორის წიგნიდან

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

ავტორის წიგნიდან

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