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

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

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

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

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

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

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

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

თანამშრომლობის სქემა

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

განლაგების სქემა

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

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

განლაგების სქემის შემუშავებისას შემდეგი მიზნები ხორციელდება:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

o "წყარო" - ფაილი პროგრამის საწყისი კოდის საშუალებით;

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

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

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

ფიგურა: 15.3. სექციები

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

ფიგურა: 15.4. ინტერფეისის ჩვენების მეთოდები

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

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

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

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

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

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

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

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

ფიგურა: 15.5 კომპონენტის დიაგრამის ფრაგმენტი, რომელიც განსაზღვრავს კოდის სტრუქტურას

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

კომპონენტური დიაგრამა და მისი აგების მახასიათებლები

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

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

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

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

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

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

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

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

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

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

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

პროგრამული სისტემის შესრულებადი ვერსიის მახასიათებლები.

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

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

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

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

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

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

ფიგურა: 10.1. კომპონენტის ნახაზი UML- ში

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

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

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

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

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

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

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

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

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

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

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

მეორე, კომპონენტებია სამუშაო პროდუქტები. როგორც წესი, ეს არის ფაილები პროგრამების საწყისი კოდებით, მაგალითად, C ++ ენის h ან cp გაფართოებებით (ნახ. 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

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

შენიშვნა 72

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

შენიშვნა 73

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

შენიშვნა 74

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

შენიშვნა 75

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