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

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

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

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

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

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

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

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

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

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

· აჩვენეთ ურთიერთქმედება ობიექტების ნაკრები რეალურ გარემოში „ჩიტის თვალთახედვიდან“;

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

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

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

როდესაც ვსაუბრობთ თანამშრომლობის დიაგრამებზე, ხშირად აღინიშნება ასეთი დიაგრამების ორი "დონე":

· ინსტანციის დონე(მაგალითები, Instance-Level): აჩვენებს ობიექტებს შორის ურთიერთქმედებას (კლასის ინსტანციები); ისე დიაგრამაჩვეულებრივ შექმნილია შესასწავლად შიდა ორგანიზაციაობიექტზე ორიენტირებული სისტემა.

· სპეციფიკაციის დონე(Specification-Level): გამოიყენება სისტემაში ძირითადი კლასების მიერ შესრულებული როლების შესასწავლად.

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

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

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

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

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

· იმპლემენტაციები კომპონენტებსა და ინტერფეისებს შორის (კომპონენტი ახორციელებს ინტერფეისს);

· დამოკიდებულებები კომპონენტებსა და ინტერფეისებს შორის (კომპონენტი იყენებს ინტერფეისს) 3.

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

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

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

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

· სისტემის კომპონენტების განაწილების განსაზღვრა მისი ფიზიკური კვანძების მიხედვით;

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

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

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

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

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

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

სისტემის შესრულებადი ვერსიის დაზუსტება.

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

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

ბრინჯი. 15.2. კომპონენტის მაგალითები

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

კომპონენტებს შეიძლება ჰქონდეთ შემდეგი სტანდარტული სტერეოტიპები:

- "ფაილი" - ნებისმიერი ფაილი, გარდა ცხრილისა:

o "შესასრულებელი" - პროგრამა (შესრულებადი ფაილი);

o „ბიბლიოთეკა“ - სტატიკური ან დინამიური ბიბლიოთეკა;

o "source" - ფაილი პროგრამის საწყისი კოდით;

o "დოკუმენტი" - სხვა ფაილები (მაგალითად, დახმარების ფაილი);

- "ცხრილი" - მონაცემთა ბაზის ცხრილი.

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

ბრინჯი. 15.3. კომპონენტი სექციებით

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

ბრინჯი. 15.4. ინტერფეისის ჩვენების მეთოდები

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

ერთი კომპონენტის (დამოკიდებული) კლასების მეთოდებში იწოდება მეთოდები ან სხვა კომპონენტის (დამოუკიდებელი) კლასების ატრიბუტები;

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

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

მონაცემთა ბაზის ცხრილებს შორის ურთიერთობა;

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

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

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

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

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

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

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

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

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

აჩვენეთ კლასები კომპონენტის სიმბოლოში.

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

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

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

Მოქმედების გეგმა

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

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

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

გამოყენების მაგალითი

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

UML 1-ში იყო კომპონენტის ცალკე სიმბოლო (სურათი 14.1). ვ UML 2ეს ხატულა არ არის, მაგრამ თქვენ შეგიძლიათ მონიშნოთ კლასის მართკუთხედი მსგავსი ხატით. ან შეგიძლიათ გამოიყენოთ საკვანძო სიტყვა « კომპონენტი» ( კომპონენტი).

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

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

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

კომპონენტები არ არის ტექნოლოგია. ტექნიკოსებს უჭირთ მათი გაგება. კომპონენტები უფრო მეტად მომხმარებელთან ურთიერთობის სტილია პროგრამული უზრუნველყოფა... მათ უნდათ, რომ შეძლონ შეიძინონ მათთვის საჭირო პროგრამული უზრუნველყოფა ნაწილებად და ასევე შეძლონ მისი განახლება ისე, როგორც განაახლებს მათ სტერეოს. მათ სურთ, რომ ახალმა კომპონენტებმა იმუშაონ ისევე, როგორც ძველებმა და განაახლონ ისინი თავიანთი გეგმების მიხედვით და არა მწარმოებლების მითითებით. მათ უნდათ სისტემები სხვადასხვა მწარმოებლებიშეეძლოთ ერთად მუშაობდნენ და ურთიერთშემცვლელნი იყვნენ. ეს ძალიან გონივრული მოთხოვნებია. ერთი დაჭერა: მათი შესრულება რთულია.
რალფ ჯონსონი, http://www.c2.com/cgi/wiki?DoComponentsExist

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

გამოიწერეთ საიტის სიახლეები, შეგიძლიათ იპოვოთ გამოწერის ფორმა საიტის მარჯვენა სვეტში.

თუ გსურთ ისწავლოთ პროფესიონალურად თავისუფალი, გეპატიჟებით კურსზე "".

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

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

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

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

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

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

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

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

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

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

3.4.3. კომპონენტებისა და განლაგების დიაგრამების გამოყენება

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

კომპონენტის დიაგრამა და მისი კონსტრუქციის თავისებურებები

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

ბრინჯი. 10.1.კომპონენტის დახატვა UML-ში

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

კომპონენტის სახელი

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

თუ კომპონენტი წარმოდგენილია ინსტანციის დონეზე, მაშინ იწერება მისი სახელი<имя компонента ":" имя типаХ При этом вся строка имени подчеркивается.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

პირველ შემთხვევაში, კლიენტის კომპონენტიდან იმპორტირებულ ინტერფეისამდე იხატება ისარი (სურათი 10.4). ასეთი ისრის არსებობა ნიშნავს, რომ კომპონენტი არ ახორციელებს შესაბამის ინტერფეისს, მაგრამ იყენებს მას შესრულების დროს. უფრო მეტიც, იგივე დიაგრამა შეიძლება შეიცავდეს სხვა კომპონენტს, რომელიც ახორციელებს ამ ინტერფეისს. ასე, მაგალითად, კომპონენტის დიაგრამის ფრაგმენტი, რომელიც ნაჩვენებია ქვემოთ, გვაწვდის ინფორმაციას იმის შესახებ, რომ კომპონენტი სახელად „main.exe“ დამოკიდებულია იმპორტირებულ I Dialog ინტერფეისზე, რომელიც, თავის მხრივ, განხორციელებულია კომპონენტის მიერ სახელად „image.java“. მეორე კომპონენტისთვის, იგივე ინტერფეისი ექსპორტირებულია.

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

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

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

ბრინჯი. 10.5.კომპონენტებს შორის დამოკიდებულების ურთიერთობის დახატვა

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

შენიშვნები:

შენიშვნა 7

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

შენიშვნა 72

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

შენიშვნა 73

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

შენიშვნა 74

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

შენიშვნა 75

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