რა სახის მოდელები არსებობს uml-ში. UML ენის ზოგადი მახასიათებლები. ურთიერთქმედების მიმოხილვის დიაგრამები

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 - Unified Modeling Language. წინა ლექციაზე ვისაუბრეთ რა არის UML, მისი ისტორია, მიზანი, ენის გამოყენების გზები, მისი განმარტების სტრუქტურა, ტერმინოლოგია და აღნიშვნა. აღინიშნა, რომ UML მოდელი არის დიაგრამების ნაკრები. ამ ლექციაში განვიხილავთ ასეთ კითხვებს: რატომ გვჭირდება რამდენიმე ტიპის დიაგრამა; დიაგრამების ტიპები; OOP და თანმიმდევრობის დიაგრამა

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

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

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

რატომ გჭირდებათ მრავალი ტიპის დიაგრამები

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

სქემების ტიპები

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

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

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

თუმცა, ზუსტი რიცხვი კანონიკური დიაგრამებიეს ჩვენთვის აბსოლუტურად უმნიშვნელოა, რადგან ჩვენ არ განვიხილავთ ყველა მათგანს, მაგრამ მხოლოდ ზოგიერთს - იმ მიზეზით, რომ კონკრეტული აპლიკაციის კონკრეტული მოდელისთვის დიაგრამების ტიპების რაოდენობა მკაცრად არ არის დაფიქსირებული. მარტივი აპლიკაციებისთვის, არ არის საჭირო ყველა დიაგრამის აგება გამონაკლისის გარეშე. მაგალითად, ლოკალური აპლიკაციისთვის, არ არის აუცილებელი განლაგების დიაგრამის აგება. მნიშვნელოვანია გვესმოდეს, რომ დიაგრამების სია დამოკიდებულია შემუშავებული პროექტის სპეციფიკაზე და განისაზღვრება თავად დეველოპერის მიერ. თუ ცნობისმოყვარე მკითხველს მაინც სურს იცოდეს ყველა UML დიაგრამა, ჩვენ მას მივმართავთ UML სტანდარტს (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). შეგახსენებთ, რომ ამ კურსის მიზანი არ არის UML-ის აბსოლუტურად ყველა შესაძლებლობის აღწერა, არამედ მხოლოდ ამ ენის გაცნობა, ამ ტექნოლოგიის თავდაპირველი წარმოდგენის მიცემა.

ასე რომ, ჩვენ მოკლედ განვიხილავთ ისეთ სქემებს, როგორიცაა:

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

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

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

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

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

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

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

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

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

განმარტება საკმაოდ გასაგები და ამომწურავია, მაგრამ მისი შემდგომი დახვეწა შესაძლებელია ზიკომ მენტორი"om:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• მე-2 კლასებს შორის კავშირი (ბევრი დამატებითი დეტალებით);
• განზოგადება მე-3 კლასებს შორის;
• დამოკიდებულებები (სხვადასხვა ტიპის) 4 კლასებს შორის და კლასებსა და ინტერფეისებს შორის.

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

1.5.3. ავტომატური დიაგრამა

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

UML-ის უპირატესობები

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

UML დიაგრამების ტიპები

UML-ში 14 ტიპის დიაგრამაა. ისინი შეიძლება დაიყოს 2 კატეგორიად:

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

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

სტრუქტურული დიაგრამები

1. კლასის დიაგრამაობიექტზე ორიენტირებული მოდელირების მთავარი ელემენტია. ამ დიაგრამის დახმარებით (ფაქტობრივად, მეშვეობით კლასები, მათი ატრიბუტები, მეთოდებიდა კლასებს შორის დამოკიდებულებები) აღწერს დომენის მოდელს და მოდელირებული სისტემის სტრუქტურას.
2. კომპონენტის დიაგრამააჩვენებს პროგრამის კოდის დაყოფას დიდ ბლოკებად (სტრუქტურულ კომპონენტებად) და აჩვენებს დამოკიდებულებებიმათ შორის. კომპონენტები შეიძლება იყოს პაკეტები, მოდულები, ბიბლიოთეკები, ფაილები და ა.შ.
3. ობიექტის დიაგრამააჩვენებს სიმულირებული სისტემის სრულ ან ნაწილობრივ ჭრას დროის მოცემულ მომენტში. იგი წარმოადგენს კლასების (ობიექტების), მათ მდგომარეობას (მიმდინარე ატრიბუტების მნიშვნელობებს) და მათ შორის ურთიერთობებს.
4. კომპოზიტური სტრუქტურის დიაგრამააჩვენებს კლასების შიდა სტრუქტურას და, თუ შესაძლებელია, ამ სტრუქტურის ელემენტებს შორის ურთიერთქმედებას.
5. პაკეტის დიაგრამააჩვენებს პაკეტებს და მათ შორის კავშირებს. ამ ტიპის დიაგრამა ემსახურება მოდელის სტრუქტურის გამარტივებას (და, შესაბამისად, მასთან მუშაობას) მოდელის ელემენტების ჯგუფებად გაერთიანებით გარკვეული კრიტერიუმების მიხედვით.
6. განლაგების დიაგრამამოდელირებს პროგრამული კომპონენტების განლაგებას ( არტეფაქტები) გამოთვლით რესურსებზე/ტექნიკის კომპონენტებზე ( კვანძები).
7. პროფილის დიაგრამააღწერს გაფართოების მექანიზმს, რომელიც საშუალებას აძლევს UML-ის ადაპტირებას სხვადასხვა საგნობრივ სფეროებსა და საქმიანობის სფეროებში.

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

ქცევის დიაგრამები

1. აქტივობის დიაგრამააჩვენებს მოქმედებებს ( მოქმედებები) რომელთაგან ზოგიერთი აქტივობა ( აქტივობა). აქტივობის დიაგრამები გამოიყენება ბიზნეს პროცესების, ტექნოლოგიური პროცესების, სერიული და პარალელური გამოთვლების მოდელირებისთვის.
2. გამოიყენეთ საქმის დიაგრამა(ან გამოყენების შემთხვევაში დიაგრამა) აღწერს მსახიობებს (მსახიობებს) და სიმულირებული სისტემის გამოყენების შემთხვევებს შორის ურთიერთობას (მის შესაძლებლობებს). დიაგრამის მთავარი მიზანია იყოს უნივერსალური ინსტრუმენტი მომხმარებლებისთვის, დეველოპერებისთვის და საბოლოო მომხმარებლებისთვის, რომლის დახმარებით შესაძლებელი იქნებოდა სისტემის - მისი შესაძლებლობებისა და ქცევის ერთობლივი განხილვა.
3. სახელმწიფო დიაგრამაასახავს ერთეულის დინამიურ ქცევას, აჩვენებს, თუ როგორ რეაგირებს ეს ერთეული, მისი ამჟამინდელი მდგომარეობიდან გამომდინარე, სხვადასხვა მოვლენებზე. სინამდვილეში, ეს არის მდგომარეობის დიაგრამა ატომების თეორიიდან.
4. კომუნიკაციის დიაგრამა(ადრე ვერსიებში თანამშრომლობის დიაგრამა) აჩვენებს კომპოზიციური სტრუქტურის ნაწილებსა და თანამშრომლობის როლებს შორის ურთიერთქმედებებს. დიაგრამა ცალსახად მიუთითებს ელემენტებს (ობიექტებს) შორის ურთიერთობას.
5. თანმიმდევრობის დიაგრამაგამოიყენება ობიექტების ურთიერთქმედების თანმიმდევრობის ვიზუალიზაციისთვის. გვიჩვენებს მოცემული ობიექტის სასიცოცხლო ციკლს და მსახიობების (მსახიობების) ურთიერთქმედებას გარკვეული გამოყენების შემთხვევაში, შეტყობინებების თანმიმდევრობას, რომელსაც ისინი ცვლიან.
6. ურთიერთქმედების მიმოხილვის დიაგრამამოიცავს მიმდევრობის დიაგრამის ნაწილს და საკონტროლო ნაკადის კონსტრუქციას. ხელს უწყობს ობიექტების ურთიერთქმედების განხილვას სხვადასხვა თვალსაზრისით.
7. დროის დიაგრამა- ურთიერთქმედების დიაგრამების ცალკეული ქვესახეობა, სპეციალიზირებული დროში. ამ ტიპის დიაგრამები გამოიყენება გარკვეული პერიოდის განმავლობაში ობიექტების ქცევის შესასწავლად.