რა არის UML?
საძიებო სისტემებში სურათებს თუ დააკვირდებით, ცხადი ხდება UML- ეს ეხება სქემებს, ისრებს და კვადრატებს. მთავარია, რომ UML ითარგმნება როგორც უნიფიცირებული მოდელირების ენა. სიტყვა ერთიანი აქ მნიშვნელოვანია. ანუ ჩვენი სურათები გაიგებს არა მხოლოდ ჩვენ, არამედ სხვებსაც, ვინც UML იცის. თურმე ეს ისეთი საერთაშორისო ენაა დიაგრამების სახატავად.
როგორც ვიკიპედია ამბობს
UML არის გრაფიკული აღწერის ენა ობიექტების მოდელირებისთვის პროგრამული უზრუნველყოფის შემუშავების, ბიზნეს პროცესის მოდელირების, სისტემების ინჟინერიისა და ორგანიზაციული სტრუქტურების რუქების დარგში.ყველაზე საინტერესო, რაზეც ყველა არ ფიქრობს ან გამოცნობს არის ის, რომ UML-ს აქვს სპეციფიკაციები. უფრო მეტიც, არსებობს UML2 სპეციფიკაციაც კი. დამატებითი ინფორმაცია სპეციფიკაციის შესახებ შეგიძლიათ იხილოთ Object Management Group ვებსაიტზე. სინამდვილეში, ეს ჯგუფი დაკავებულია UML სპეციფიკაციების შემუშავებით. ასევე საინტერესოა, რომ UML არ შემოიფარგლება მხოლოდ კლასების სტრუქტურის აღწერით. არსებობს მრავალი სახის UML დიაგრამები. UML დიაგრამების ტიპების მოკლე აღწერა შეგიძლიათ იხილოთ იმავე ვიკიპედიაში: UML დიაგრამები ან ტიმურ ბატირშინოვის ვიდეოში. UML დიაგრამების მიმოხილვა. UML ასევე ფართოდ გამოიყენება სხვადასხვა პროცესების აღწერისას, მაგალითად აქ: ერთჯერადი შესვლა JWT-ის გამოყენებით. UML კლასის დიაგრამების გამოყენებას რომ დავუბრუნდეთ, აღსანიშნავია წიგნი Head First: Design Patterns, რომელშიც შაბლონები ილუსტრირებულია იმავე UML დიაგრამებით. გამოდის, რომ UML ნამდვილად გამოიყენება. და გამოდის, რომ მისი გამოყენების ცოდნა და გაგება საკმაოდ სასარგებლო უნარია.
განაცხადი
ვნახოთ, როგორ შეგიძლიათ მუშაობა ამ UML-თან IDE-დან. როგორც IDE, მიიღეთ IntelliJ იდეა. გამოყენების შემთხვევაში IntelliJ Idea Ultimate, მაშინ ჩვენ გვექნება დაინსტალირებული დანამატი "გარეშე" UML მხარდაჭერა". ის საშუალებას გაძლევთ ავტომატურად შექმნათ ლამაზი კლასის დიაგრამები. მაგალითად, Ctrl + N ან მენიუს პუნქტის "Navigate" -> "Class" გადადით კლასში. ArrayList. ახლა, კონტექსტური მენიუდან კლასის სახელით, აირჩიეთ "დიაგრამა" -> "დიაგრამის ამომხტარის ჩვენება". შედეგად, ჩვენ ვიღებთ მშვენიერ სქემას:
მაგრამ რა მოხდება, თუ გინდათ დახატოთ საკუთარი თავი და არ არსებობს იდეის საბოლოო ვერსია? თუ ჩვენ ვიყენებთ IntelliJ Idea Community Edition-ს, მაშინ სხვა არჩევანი არ გვაქვს. ამისათვის თქვენ უნდა გესმოდეთ, თუ როგორ მუშაობს ასეთი UML სქემა. ჯერ უნდა დავაყენოთ Graphviz. ეს არის გრაფიკის ვიზუალიზაციის საშუალებების ნაკრები. მას იყენებს დანამატი, რომელსაც ჩვენ გამოვიყენებთ. ინსტალაციის შემდეგ, თქვენ უნდა დაამატოთ დირექტორია ურნადაინსტალირებული დირექტორიადან graphvizგარემოს ცვლადს ბილიკი. ამის შემდეგ IntelliJ Idea-ში მენიუდან აირჩიეთ File -> Settings. "პარამეტრების" ფანჯარაში აირჩიეთ "Plugins" კატეგორია, დააჭირეთ ღილაკს "Browse repositories" და დააინსტალირეთ PlantUML ინტეგრაციის მოდული. რატომ არის ეს ასე კარგი PlantUML? იგი იყენებს გრაფიკის აღწერის ენას სახელწოდებით " წერტილიდა ეს საშუალებას აძლევს მას იყოს უფრო უნივერსალური, რადგან ამ ენას იყენებს არა მხოლოდ PlantUML. უფრო მეტიც, ყველაფერი, რასაც ქვემოთ გავაკეთებთ, შეიძლება გაკეთდეს არა მხოლოდ IDE-ში, არამედ planttext.com ონლაინ სერვისშიც. ინსტალაციის შემდეგ PlantUML მოდული, ჩვენ შევძლებთ შევქმნათ UML დიაგრამები "ფაილი" -> "ახალი" საშუალებით. მოდით შევქმნათ "UML კლასის" ტიპის დიაგრამა. ამ დროს ავტომატურად წარმოიქმნება შაბლონი მაგალითით. მოდით წავშალოთ მისი შინაარსი და შევქმნათ ჩვენი საკუთარი, შეიარაღებული სტატიით Habr-დან: კლასური ურთიერთობები - UML-დან კოდამდე... და იმის გასაგებად, თუ როგორ უნდა გამოვსახოთ ეს ტექსტში, ავიღოთ PlantUML სახელმძღვანელო: plantuml კლასი-დიაგრამა... მასში, თავიდანვე, არის ნიშანი იმისა, თუ როგორ უნდა აღწერო ურთიერთობები:
თავად კავშირების შესახებ, ჩვენ ჯერ კიდევ შეგვიძლია აქ ვიხილოთ: "ურთიერთობები კლასებს შორის UML-ში. მაგალითები". ამ მასალებზე დაყრდნობით, დავიწყოთ ჩვენი UML დიაგრამის შექმნა. დაამატეთ შემდეგი შინაარსი, რომელიც აღწერს ორ კლასს: @startuml class ArrayList ( ) class LinkedList ( ) @enduml Idea-ში შედეგის სანახავად აირჩიეთ "View" -> "Tool Windows" -> "PlantUML". ჩვენ მივიღებთ მხოლოდ ორ კვადრატს, რომელიც აღნიშნავს კლასებს. როგორც ვიცით, ორივე კლასი ახორციელებს List ინტერფეისს. კლასების ამ მიმართებას ეწოდება - განხორციელება (რეალიზაცია). ასეთი ურთიერთობის გამოსახატავად გამოიყენება ისარი წერტილოვანი ხაზით. მოდით დავხატოთ: ინტერფეისის სიის სია< | . . ArrayList List < | . . LinkedList List - один из дочерних классов Collection . То есть он наследуется от Collection. Эта связь называется обобщением (generalization). Выглядит как стрелка с обычной непрерывной линией. Изобразим её: interface Collection Collection < | -- List Для следующего типа связи добавим в описание класса ArrayList запись о პაკეტი პირადიელემენტის მასივი: ~ Object elementData ახლა ჩვენ გვინდა ვაჩვენოთ, რომ ArrayList შეიცავს რამდენიმე ობიექტს. ამ შემთხვევაში, კავშირის ტიპი იქნება - აგრეგაცია(აგრეგაცია). აგრეგატი ამ შემთხვევაში არის ArrayList, რადგან ის შეიცავს სხვა ობიექტებს. ჩვენ ვირჩევთ აგრეგაციას, რადგან სიის ობიექტებს შეუძლიათ იცხოვრონ სიის გარეშე: ისინი არ არიან მისი განუყოფელი ნაწილები. მათი სიცოცხლე არ არის მიბმული სიის სიცოცხლესთან. ერთეული ლათინურიდან ითარგმნება როგორც "შეგროვებული", ანუ რაღაცისგან შემდგარი. მაგალითად, ცხოვრებაში არის სატუმბი დანადგარი, რომელიც შედგება ტუმბოსა და ძრავისგან. თავად ერთეული შეიძლება დაიშალა, დატოვოს მისი ზოგიერთი კომპონენტი. მაგალითად, გაყიდვა ან სხვა ერთეულის ჩასმა. ასე რომ, სიაშია. და ეს გამოიხატება ცარიელი რომბის სახით ერთეულზე და უწყვეტი ხაზით. მოდით ასე ვთქვათ: კლასი Object ( ) ArrayList o- Object ახლა გვინდა ვაჩვენოთ, რომ ArrayList-ისგან განსხვავებით, LinkedList კლასი შეიცავს Node კონტეინერებს, რომლებიც ეხება შენახულ მონაცემებს. ამ შემთხვევაში კვანძები თავად LinkedList-ის ნაწილია და არ შეუძლიათ ცალკე ცხოვრება. Node არ არის უშუალოდ შენახული შინაარსი, მაგრამ შეიცავს მხოლოდ მასზე მითითებას. მაგალითად, როდესაც LinkedList-ს ვამატებთ მწკრივს, ვამატებთ ახალ Node-ს, რომელიც შეიცავს ბმულს ამ მწკრივზე, ისევე როგორც ბმულს წინა და შემდეგი კვანძისთვის. ამ ტიპის კავშირი ე.წ შემადგენლობა(კომპოზიცია). კომპოზიტის საჩვენებლად (ის, რომელიც შედგება ნაწილებისგან), შედგენილია შევსებული რობი, უწყვეტი ხაზი მივყავართ მას. ახლა მოდით დავწეროთ ეს, როგორც ბმულის ტექსტური ჩვენება: class Node ( ) LinkedList * -- Node და ახლა ჩვენ უნდა ვისწავლოთ როგორ გამოვაჩინოთ სხვა მნიშვნელოვანი ტიპის ბმული - დამოკიდებულება(დამოკიდებულების ურთიერთობა). იგი გამოიყენება, როდესაც ერთი კლასი იყენებს მეორეს, ხოლო კლასი არ შეიცავს გამოყენებულ კლასს და არ არის მისი მემკვიდრე. მაგალითად, LinkedList-ს და ArrayList-ს შეუძლიათ შექმნან ListIterator. მოდით გამოვხატოთ ეს წერტილოვანი ისრების სახით: class ListIterator ListIterator< . . . ArrayList : create ListIterator < . . . LinkedList : create Выглядеть после всего это будет следующим образом:
შეგიძლიათ დეტალურად დაწვრილებით, რამდენიც გჭირდებათ. ყველა აღნიშვნა ჩამოთვლილია აქ: "PlantUML - კლასის დიაგრამა". გარდა ამისა, ასეთი სქემის დახატვაში არაფერია ზებუნებრივი და დავალებებზე მუშაობისას, შეგიძლიათ სწრაფად დახატოთ ხელით. ეს განავითარებს თქვენი აპლიკაციის არქიტექტურის აზროვნების უნარს და დაგეხმარებათ კლასის სტრუქტურის ხარვეზების ადრეულ ეტაპზე გამოვლენაში და არა მას შემდეგ, რაც უკვე გაატარეთ ერთი დღე არასწორი მოდელის განხორციელებაზე. ვფიქრობ, ეს კარგი მიზეზია სცადოთ?)
ავტომატიზაცია
PlantUML დიაგრამების ავტომატურად გენერირების სხვადასხვა გზა არსებობს. მაგალითად, in იდეებიარის SketchIT მოდული, მაგრამ ის მათ სწორად არ ხატავს. მაგალითად, ინტერფეისების განხორციელება არასწორად არის დახატული (გამოსახულია მემკვიდრეობით). ასევე არსებობს ონლაინ მაგალითები იმის შესახებ, თუ როგორ უნდა ჩართოთ ეს თქვენი პროექტის სასიცოცხლო ციკლში. ვთქვათ ამისთვის მეივენიარსებობს მაგალითი, რომელიც იყენებს uml-java-docklet-ს. იმის საჩვენებლად, თუ როგორ კეთდება ეს, გამოვიყენოთ Maven არქეტიპი, რათა სწრაფად შევქმნათ Maven პროექტი. მოდით შევასრულოთ ბრძანება: mvn archetype:generate ფილტრის არჩევის შესახებ ( აირჩიეთ ნომერი ან გამოიყენეთ ფილტრი) დატოვეთ ნაგულისხმევი უბრალოდ Enter დაჭერით. ყოველთვის იქნება" maven-archetype-სწრაფი დაწყება". ვირჩევთ უახლეს ვერსიას. შემდეგ უპასუხეთ კითხვებს და დაასრულეთ პროექტის შექმნა:
ვინაიდან Maven არ არის ამ სტატიის ფოკუსირება, Maven-ის შესახებ თქვენს კითხვებზე პასუხები შეგიძლიათ იხილოთ Maven-ის მომხმარებელთა ცენტრში. გენერირებულ პროექტში გახსენით პროექტის აღწერილობის ფაილი რედაქტირებისთვის, pom.xml. ჩვენ დავაკოპირებთ მასში uml-java-docklet-ის ინსტალაციის აღწერილობის შიგთავსს. აღწერილობაში გამოყენებული არტეფაქტი ვერ მოიძებნა Maven Central საცავში. მაგრამ ეს მუშაობდა ამით: https://mvnrepository.com/artifact/com.chfourie/uml-java-doclet/1.0.0. ანუ, ამ აღწერაში თქვენ უბრალოდ უნდა შეცვალოთ ჯგუფის IDსაწყისი " info.leadinglight" ზე " com.chfourie"და დააყენე ვერსია" 1.0.0 ამის შემდეგ ჩვენ შეგვიძლია შევასრულოთ იმ დირექტორიაში, სადაც ფაილი მდებარეობს pom.xmlეს ბრძანებებია: mvn clean install და mvn javadoc:javadoc . ახლა, თუ ჩვენ გავხსნით გენერირებულ დოკუმენტაციას (explorer target\site\apidocs\index.html), დავინახავთ UML დიაგრამებს. სხვათა შორის, განხორციელება უკვე სწორად არის ნაჩვენები აქ)
დასკვნა
როგორც ხედავთ, UML გაძლევთ საშუალებას წარმოიდგინოთ თქვენი განაცხადის სტრუქტურა. ასევე, UML არ შემოიფარგლება მხოლოდ ამით. UML-ის დახმარებით თქვენ შეგიძლიათ აღწეროთ სხვადასხვა პროცესები თქვენს კომპანიაში ან აღწეროთ ბიზნეს პროცესი, რომლის ფარგლებშიც მუშაობს ფუნქცია, რომელსაც თქვენ წერთ. რამდენად სასარგებლოა UML თქვენთვის პირადად, თქვენზეა დამოკიდებული, მაგრამ დროის გამონახვა და მისი უფრო დეტალური გაცნობა მაინც სასარგებლო იქნება. #ვიაჩესლავ ამ პოსტის რუსული ვერსია: UML დიაგრამა Java CodeGym-ზეᲐნოტაცია: ამ კურსის საგანია UML - Unified Modeling Language. წინა ლექციაზე ვისაუბრეთ რა არის UML, მის ისტორიაზე, დანიშნულებაზე, ენის გამოყენების გზებზე, მისი განმარტების სტრუქტურაზე, ტერმინოლოგიასა და აღნიშვნაზე. აღინიშნა, რომ UML მოდელი არის დიაგრამების ნაკრები. ამ ლექციაში განვიხილავთ ასეთ კითხვებს: რატომ გვჭირდება რამდენიმე ტიპის დიაგრამა; დიაგრამების ტიპები; 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).
ყურადღებიან მკითხველს შეუძლია დაუყოვნებლივ დაუსვას შეკითხვა: რატომ არის ჰექტორი და არა მსახიობი?? გეთანხმებით, სიტყვა „ექტორ“ რუსს ცოტა ყურს ჭრის. მიზეზი, რის გამოც ჩვენ ამას ვამბობთ, მარტივია - ექტორი წარმოიქმნება სიტყვისგან მოქმედება, რაც თარგმანში ნიშნავს მოქმედება. სიტყვა "ექტორის" პირდაპირი თარგმანი - მსახიობი- ძალიან გრძელი და არასასიამოვნო გამოსაყენებლად. ამიტომ, ჩვენ გავაგრძელებთ ამის თქმას.
ბრინჯი. 2.1.
იგივე ყურადღებიანმა მკითხველმა შეამჩნია, რომ სიტყვა „პრეცედენტი“ ციმციმებდა ექტორის განმარტებაში. Რა არის ეს? ეს კითხვა კიდევ უფრო გვაინტერესებს, თუ გავიხსენებთ, რაზეც ახლა ვსაუბრობთ გამოყენების შემთხვევაში დიაგრამა. Ისე,
პრეცედენტი (გამოყენების შემთხვევა)- სისტემის ქცევის კონკრეტული ასპექტის აღწერა მომხმარებლის თვალსაზრისით (Butch).
განმარტება საკმაოდ გასაგები და ამომწურავია, მაგრამ მისი შემდგომი დახვეწა შესაძლებელია ზიკომ მენტორი"om:
გამოყენების შემთხვევაში- სისტემის მიერ შესრულებული თანმიმდევრული მოვლენების სიმრავლის (მათ შორის ვარიანტების) აღწერა, რაც იწვევს აქტორის მიერ დაკვირვებულ შედეგს. გამოყენების შემთხვევა წარმოადგენს ერთეულის ქცევას აქტორებსა და სისტემას შორის ურთიერთქმედების აღწერით. პრეცედენტი არ აჩვენებს "როგორ" მიიღწევა გარკვეული შედეგი, არამედ მხოლოდ "რა" არის.
პრეცედენტები მითითებულია ძალიან მარტივი გზით - ელიფსის სახით, რომლის შიგნით მისი სახელია მითითებული. გამოყენების შემთხვევები და მსახიობები დაკავშირებულია ხაზებით. ხშირად ხაზის ერთ ბოლოზე გამოსახულია ბრინჯი. 2.3
UML არის სტანდარტული ნოტაცია პროგრამული სისტემების ვიზუალური მოდელირებისთვის, რომელიც მიღებული იქნა Object Managing Group (OMG) მიერ 1997 წლის შემოდგომაზე და მხარდაჭერილია მრავალი ობიექტზე ორიენტირებული CASE პროდუქტის მიერ.
UML სტანდარტი გთავაზობთ დიაგრამების შემდეგ კომპლექტს მოდელირებისთვის:
Use case დიაგრამა (use case diagram) - ორგანიზაციის ან საწარმოს ბიზნეს პროცესების მოდელირებისთვის და შექმნილ საინფორმაციო სისტემაზე მოთხოვნების განსაზღვრისათვის;
კლასის დიაგრამა (კლასის დიაგრამა) - სისტემის კლასების სტატიკური სტრუქტურისა და მათ შორის ურთიერთობის მოდელირებისთვის;
სისტემის ქცევის დიაგრამა (ქცევის დიაგრამები);
ურთიერთქმედების დიაგრამები;
თანმიმდევრობის დიაგრამები - ობიექტებს შორის შეტყობინების პროცესის მოდელირებისთვის ერთი გამოყენების შემთხვევაში;
თანამშრომლობის დიაგრამა (თანამშრომლობის დიაგრამა) - ობიექტებს შორის შეტყობინების პროცესის მოდელირებისთვის იმავე გამოყენების შემთხვევაში;
statechart დიაგრამა - სისტემის ობიექტების ქცევის მოდელირებისთვის ერთი მდგომარეობიდან მეორეში გადასვლისას;
აქტივობის დიაგრამა - სისტემის ქცევის მოდელირებისთვის სხვადასხვა გამოყენების შემთხვევების, ან მოდელირების აქტივობების ფარგლებში;
განხორციელების დიაგრამა (განხორციელების დიაგრამები):
კომპონენტის დიაგრამები (კომპონენტური დიაგრამები) - საინფორმაციო სისტემის კომპონენტების (ქვესისტემების) იერარქიის მოდელირებისთვის;
განლაგების დიაგრამა (განლაგების დიაგრამა) - დაპროექტებული საინფორმაციო სისტემის ფიზიკური არქიტექტურის მოდელირებისთვის.
ნახ. 1.1 წარმოგიდგენთ საინფორმაციო სისტემის ინტეგრირებულ მოდელს, ამ კურსის პროექტში შესამუშავებელი ძირითადი დიაგრამების ჩათვლით.
ბრინჯი. 1. საინფორმაციო სისტემის ინტეგრირებული მოდელი UML ენის აღნიშვნით
4.2. გამოიყენეთ საქმის დიაგრამა
გამოყენების შემთხვევა არის მოქმედებების თანმიმდევრობა, რომელსაც სისტემა ასრულებს რაიმე გარე ობიექტის (აქტორის) მიერ გამოწვეულ მოვლენის საპასუხოდ. გამოყენების შემთხვევა აღწერს ტიპიურ ურთიერთქმედებას მომხმარებელსა და სისტემას შორის. უმარტივეს შემთხვევაში გამოყენების შემთხვევა განისაზღვრება მომხმარებელთან იმ ფუნქციების განხილვის პროცესში, რომელთა განხორციელებაც მას სურს ამ საინფორმაციო სისტემაში. UML-ში გამოყენების შემთხვევა გამოსახულია შემდეგნაირად:
ნახ.2. Გამოყენების შემთხვევაში
მსახიობი არის როლი, რომელსაც მომხმარებელი ასრულებს სისტემასთან მიმართებაში. მსახიობები წარმოადგენენ როლებს და არა კონკრეტულ ადამიანებს ან სამუშაოს. მიუხედავად იმისა, რომ ისინი გამოსახულია, როგორც სტილიზებული ადამიანის ფიგურები გამოყენების შემთხვევაში დიაგრამებში, მსახიობი ასევე შეიძლება იყოს გარე საინფორმაციო სისტემა, რომელსაც სჭირდება გარკვეული ინფორმაცია სისტემიდან. თქვენ უნდა აჩვენოთ მსახიობები დიაგრამაში მხოლოდ მაშინ, როდესაც მათ ნამდვილად სჭირდებათ გამოყენების შემთხვევები. UML-ში მსახიობები წარმოდგენილია ფორმებად:
ნახ.3. პერსონაჟი (მსახიობი)
მსახიობები იყოფა სამ ძირითად ტიპად:
მომხმარებლები
სისტემები;
სხვა სისტემები, რომლებიც ურთიერთქმედებენ ამ სისტემასთან;
დრო ხდება მოქმედი, თუ მასზეა დამოკიდებული სისტემაში რაიმე მოვლენის გაჩაღება.
4.2.1. ურთიერთობები გამოყენების შემთხვევებსა და მსახიობებს შორის
UML-ში გამოყენების შემთხვევების დიაგრამები მხარს უჭერს რამდენიმე ტიპის ურთიერთობას დიაგრამის ელემენტებს შორის:
კომუნიკაცია (კომუნიკაცია),
ჩართვა (შეიცავს),
გაფართოება (გაგრძელება),
განზოგადება.
საკომუნიკაციო კომუნიკაციაარის სარგებლობის შემთხვევისა და მსახიობის ურთიერთობა. UML-ში საკომუნიკაციო ბმულები ნაჩვენებია ცალმხრივი ასოციაციის (მყარი ხაზის) გამოყენებით.
ნახ.4. საკომუნიკაციო ბმულის მაგალითი
ინკლუზიური კავშირიგამოიყენება სიტუაციებში, როდესაც არსებობს სისტემის ქცევის გარკვეული ნაწილი, რომელიც მეორდება ერთზე მეტ გამოყენების შემთხვევაში. ასეთი ბმულების დახმარებით, ჩვეულებრივ ხდება მრავალჯერადი გამოყენების ფუნქციის მოდელირება.
გაფართოების კავშირიგამოიყენება სისტემის ნორმალური ქცევის ცვლილებების აღსაწერად. ის საშუალებას აძლევს ერთ გამოყენებას, საჭიროების შემთხვევაში გამოიყენოს სხვა გამოყენების ფუნქციები.
ნახ.5. ჩართვისა და გაფართოების ურთიერთობის მაგალითი
კომუნიკაციის განზოგადებამიუთითებს, რომ რამდენიმე აქტორს ან კლასს აქვს საერთო თვისებები.
სურ.6. განზოგადების ურთიერთობის მაგალითი
4.3.
ურთიერთქმედების დიაგრამებიაღწერეთ ობიექტების ურთიერთქმედების ჯგუფების ქცევა. როგორც წესი, ურთიერთქმედების დიაგრამა მოიცავს მხოლოდ ობიექტების ქცევას ერთი გამოყენების შემთხვევაში. ასეთი დიაგრამა აჩვენებს ობიექტთა რაოდენობას და შეტყობინებებს, რომლებსაც ისინი უცვლიან ერთმანეთს.
შეტყობინებაარის საშუალება, რომლითაც გამგზავნი ობიექტი ითხოვს მიმღებ ობიექტს მისი ერთ-ერთი ოპერაციის შესრულებას.
საინფორმაციო (საინფორმაციო) შეტყობინებაარის შეტყობინება, რომელიც მიმღებ ობიექტს აწვდის გარკვეულ ინფორმაციას მისი მდგომარეობის განახლებისთვის.
შეტყობინების მოთხოვნა (დაკითხვითი)არის შეტყობინება, რომელიც ითხოვს გარკვეული ინფორმაციის გამოტანას მიმღების ობიექტის შესახებ.
იმპერატიული მესიჯიარის შეტყობინება, რომელიც სთხოვს მიმღებს გარკვეული მოქმედების შესრულებას.
არსებობს ორი სახის ურთიერთქმედების დიაგრამები: თანმიმდევრობის დიაგრამები და თანამშრომლობის დიაგრამები.
4.3.1. თანმიმდევრობის დიაგრამები
თანმიმდევრობის დიაგრამაასახავს მოვლენათა ნაკადს, რომელიც ხდება ერთი გამოყენების შემთხვევაში.
მოცემულ სცენარში (გამოყენების შემთხვევა) ჩართული ყველა მსახიობი (მსახიობები, კლასი ან ობიექტი) ნაჩვენებია დიაგრამის ზედა ნაწილში. ისრები შეესაბამება შეტყობინებებს, რომლებიც გადაცემულია აქტორსა და ობიექტს შორის, ან ობიექტებს შორის საჭირო ფუნქციების შესასრულებლად.
თანმიმდევრობის დიაგრამაზე ობიექტი გამოსახულია მართკუთხედის სახით, საიდანაც წერტილოვანი ვერტიკალური ხაზი ქვევითაა გამოსახული. ამ ხაზს ე.წ ობიექტის მაშველი ხაზი . ეს არის ობიექტის სასიცოცხლო ციკლის ფრაგმენტი ურთიერთქმედების პროცესში.
თითოეული შეტყობინება წარმოდგენილია როგორც ისარი ორი ობიექტის სიცოცხლის ხაზებს შორის. შეტყობინებები გამოჩნდება იმ თანმიმდევრობით, როგორც ისინი გამოჩნდება გვერდზე ზემოდან ქვემოდან. თითოეულ შეტყობინებას მონიშნულია მინიმუმ შეტყობინების სახელი. სურვილისამებრ, თქვენ ასევე შეგიძლიათ დაამატოთ არგუმენტები და გარკვეული საკონტროლო ინფორმაცია. თქვენ შეგიძლიათ აჩვენოთ თვითმმართველობის დელეგირება, შეტყობინება, რომელსაც ობიექტი უგზავნის საკუთარ თავს, შეტყობინების ისრით, რომელიც მიუთითებს იმავე მაშველ ხაზზე.
ბრინჯი. 7. მიმდევრობის დიაგრამის მაგალითი
4.3.2. თანამშრომლობის დიაგრამა
თანამშრომლობის დიაგრამებიმოვლენების ნაკადის ჩვენება კონკრეტული სცენარის ფარგლებში (გამოყენების შემთხვევა). შეტყობინებები დალაგებულია დროის მიხედვით, თუმცა თანამშრომლობის დიაგრამები უფრო მეტად ფოკუსირებულია ობიექტებს შორის ურთიერთობაზე. თანამშრომლობის დიაგრამა გვიჩვენებს მთელ ინფორმაციას, რაც აქვს თანმიმდევრობის დიაგრამას, მაგრამ თანამშრომლობის დიაგრამა სხვაგვარად აღწერს მოვლენების დინებას. მისგან უფრო ადვილია ობიექტებს შორის არსებული კავშირების გაგება.
თანამშრომლობის დიაგრამაში, ისევე როგორც თანმიმდევრულ დიაგრამაში, ისრები წარმოადგენს შეტყობინებებს, რომლებიც გაცვლა ხდება მოცემული გამოყენების შემთხვევაში. მათი დროის თანმიმდევრობა მითითებულია შეტყობინებების ნუმერაციით.
ბრინჯი. 8. თანამშრომლობის სქემის მაგალითი
4.4. კლასის დიაგრამა
4.4.1. Ზოგადი ინფორმაცია
კლასის დიაგრამაგანსაზღვრავს სისტემის კლასების ტიპებს და მათ შორის არსებულ სხვადასხვა სახის სტატიკური ბმულებს. კლასის დიაგრამები ასევე აჩვენებს კლასის ატრიბუტებს, კლასის ოპერაციებს და შეზღუდვებს, რომლებიც თავსდება კლასებს შორის ურთიერთობებზე.
კლასის დიაგრამა UML-ში არის გრაფიკი, რომლის კვანძები არის პროექტის სტატიკური სტრუქტურის ელემენტები (კლასები, ინტერფეისები), ხოლო რკალი არის კვანძებს შორის ურთიერთობა (ასოციაციები, მემკვიდრეობა, დამოკიდებულებები).
კლასის დიაგრამა აჩვენებს შემდეგ ელემენტებს:
· პაკეტი (პაკეტი) - მოდელის ელემენტების ერთობლიობა, ერთმანეთთან ლოგიკურად დაკავშირებული;
· კლასი (კლასი) - მსგავსი ობიექტების ჯგუფის საერთო თვისებების აღწერა;
· ინტერფეისი (ინტერფეისი) - აბსტრაქტული კლასი, რომელიც განსაზღვრავს ოპერაციების ერთობლიობას, რომელსაც მოცემულ ინტერფეისთან დაკავშირებული თვითნებური კლასის ობიექტი აძლევს სხვა ობიექტებს.
4.4.2. Კლასი
Კლასიარის ერთეულების (ობიექტების) ჯგუფი, რომლებსაც აქვთ მსგავსი თვისებები, კერძოდ მონაცემები და ქცევა. კლასის ცალკეულ წევრს უწოდებენ კლასის ობიექტს, ან უბრალოდ ობიექტს.
UML-ში ობიექტის ქცევა გულისხმობს ობიექტის გარე სამყაროსთან და თავად ობიექტის მონაცემებთან ურთიერთქმედების ნებისმიერ წესს.
დიაგრამებში კლასი გამოსახულია მართკუთხედის სახით მყარი საზღვრით, ჰორიზონტალური ხაზებით დაყოფილი 3 ნაწილად:
ზედა განყოფილება (სახელის განყოფილება) შეიცავს კლასის სახელს და სხვა ზოგად თვისებებს (კერძოდ, სტერეოტიპს).
შუა განყოფილება შეიცავს ატრიბუტების ჩამონათვალს
ბოლოში არის კლასის ოპერაციების სია, რომლებიც ასახავს მის ქცევას (კლასის მიერ შესრულებული მოქმედებები).
ატრიბუტისა და ოპერაციების რომელიმე სექცია შეიძლება არ იყოს ნაჩვენები (ან ორივე). დაკარგული მონაკვეთისთვის, თქვენ არ გჭირდებათ გამყოფი ხაზის დახატვა და როგორმე მიუთითოთ მასში ელემენტების არსებობა ან არარსებობა.
დამატებითი სექციები, როგორიცაა გამონაკლისები, შეიძლება შემოღებულ იქნეს კონკრეტული განხორციელების შეხედულებისამებრ.
ბრინჯი. 9. კლასის დიაგრამის მაგალითი
4.4.2.1.კლასობრივი სტერეოტიპები
კლასობრივი სტერეოტიპი არის კლასების კატეგორიებად დაყოფის მექანიზმი.
UML განსაზღვრავს სამ ძირითად კლასის სტერეოტიპს:
საზღვარი (საზღვარი);
სუბიექტი (ობიექტი);
კონტროლი (მართვა).
4.4.2.2.სასაზღვრო კლასები
სასაზღვრო კლასები არის ის კლასები, რომლებიც განლაგებულია სისტემისა და მთელი გარემოს საზღვარზე. ეს არის დისპლეები, ანგარიშები, ინტერფეისები აპარატურასთან (როგორიცაა პრინტერები ან სკანერები) და ინტერფეისები სხვა სისტემებთან.
სასაზღვრო კლასების მოსაძებნად, თქვენ უნდა შეისწავლოთ გამოყენების შემთხვევების დიაგრამები. მსახიობსა და გამოყენების შემთხვევას შორის ყველა ურთიერთქმედება უნდა ჰქონდეს მინიმუმ ერთი სასაზღვრო კლასი. სწორედ ეს კლასი აძლევს მსახიობს სისტემასთან ინტერაქციის საშუალებას.
4.4.2.3.სუბიექტის კლასები
ერთეულის კლასები შეიცავს შენახულ ინფორმაციას. მათ აქვთ უდიდესი მნიშვნელობა მომხმარებლისთვის და, შესაბამისად, მათი სახელები ხშირად იყენებენ ტერმინებს საგნის არედან. ჩვეულებრივ, თითოეული ერთეულის კლასისთვის, მონაცემთა ბაზაში იქმნება ცხრილი.
4.4.2.4.საკონტროლო კლასები
საკონტროლო კლასები პასუხისმგებელნი არიან სხვა კლასების ქმედებების კოორდინაციაზე. როგორც წესი, თითოეულ გამოყენების შემთხვევას აქვს ერთი საკონტროლო კლასი, რომელიც აკონტროლებს მოვლენების თანმიმდევრობას ამ გამოყენების შემთხვევისთვის. საკონტროლო კლასი პასუხისმგებელია კოორდინაციაზე, მაგრამ თავისთავად არ ახორციელებს რაიმე ფუნქციონირებას, რადგან სხვა კლასები მას არ უგზავნიან დიდი რაოდენობით შეტყობინებებს. სამაგიეროდ, თავადაც უამრავ მესიჯს აგზავნის. მენეჯერის კლასი უბრალოდ გადასცემს პასუხისმგებლობას სხვა კლასებს, რის გამოც მას ხშირად უწოდებენ მენეჯერის კლასს.
შეიძლება არსებობდეს სხვა საკონტროლო კლასები სისტემაში, რომლებიც საერთოა რამდენიმე გამოყენების შემთხვევისთვის. მაგალითად, შეიძლება არსებობდეს SecurityManager კლასი, რომელიც პასუხისმგებელია უსაფრთხოებასთან დაკავშირებული მოვლენების მონიტორინგზე. TransactionManager კლასი ამუშავებს მონაცემთა ბაზის ტრანზაქციებთან დაკავშირებული შეტყობინებების კოორდინაციას. შეიძლება არსებობდეს სხვა მენეჯერები, რომლებიც გაუმკლავდებიან სისტემის მუშაობის სხვა ელემენტებს, როგორიცაა რესურსების გაზიარება, მონაცემთა განაწილებული დამუშავება ან შეცდომების დამუშავება.
ზემოთ ნახსენები სტერეოტიპების გარდა, შეგიძლიათ შექმნათ თქვენი საკუთარი.
4.4.2.5.ატრიბუტები
ატრიბუტი არის კლასთან დაკავშირებული ინფორმაციის ნაწილი. ატრიბუტები ინახავს კაფსულირებული კლასის მონაცემებს.
იმის გამო, რომ ატრიბუტები შეიცავს კლასს, ისინი იმალება სხვა კლასებისგან. ამის გამო, შესაძლოა საჭირო გახდეს იმის დაზუსტება, თუ რომელ კლასებს აქვთ უფლება წაიკითხონ და შეცვალონ ატრიბუტები. ამ თვისებას ეწოდება ატრიბუტის ხილვადობა.
ატრიბუტს შეიძლება ჰქონდეს ოთხი შესაძლო მნიშვნელობა ამ პარამეტრისთვის:
საჯარო (ზოგადი, ღია). ხილვადობის ეს მნიშვნელობა ვარაუდობს, რომ ატრიბუტი ხილული იქნება ყველა სხვა კლასისთვის. ნებისმიერ კლასს შეუძლია ატრიბუტის მნიშვნელობის ნახვა ან შეცვლა. UML ნოტაციის შესაბამისად, საერთო ატრიბუტს წინ უძღვის ნიშანი "+".
პირადი (დახურული, საიდუმლო). შესაბამისი ატრიბუტი არ ჩანს სხვა კლასისთვის. კერძო ატრიბუტი აღინიშნება "-" ნიშნით UML აღნიშვნის შესაბამისად.
დაცული (დაცული). ასეთი ატრიბუტი ხელმისაწვდომია მხოლოდ თავად კლასისთვის და მისი შთამომავლებისთვის. დაცული ატრიბუტის UML აღნიშვნა არის "#" სიმბოლო.
პაკეტი ან იმპლემენტაცია (სამეფო). დავუშვათ, რომ მოცემული ატრიბუტი გაზიარებულია, მაგრამ მხოლოდ მის პაკეტში. ამ ტიპის ხილვადობა არ არის მითითებული რაიმე სპეციალური ხატით.
დახურვის ან უსაფრთხოების დახმარებით შესაძლებელია თავიდან ავიცილოთ სიტუაცია, როდესაც ატრიბუტის მნიშვნელობა იცვლება სისტემის ყველა კლასის მიერ. ამის ნაცვლად, ატრიბუტის მოდიფიკაციის ლოგიკა იქნება შეფუთული იმავე კლასში, როგორც თავად ატრიბუტი. თქვენ მიერ დაყენებული ხილვადობის პარამეტრები გავლენას მოახდენს გენერირებულ კოდზე.
4.4.2.6.Ოპერაციები
ოპერაციები ახორციელებენ კლასთან დაკავშირებულ ქცევას. ოპერაციას აქვს სამი ნაწილი - სახელი, პარამეტრები და დაბრუნების ტიპი.
პარამეტრები არის არგუმენტები, რომლებსაც ოპერაცია იღებს შეყვანის სახით. დაბრუნების ტიპი ეხება ოპერაციის მოქმედების შედეგს.
კლასის დიაგრამას შეუძლია აჩვენოს როგორც ოპერაციების სახელები, ასევე ოპერაციების სახელები მათ პარამეტრებთან და დაბრუნების ტიპთან ერთად. დიაგრამაზე დატვირთვის შესამცირებლად, სასარგებლოა ზოგიერთ მათგანზე მხოლოდ ოპერაციების სახელების ჩვენება, ზოგზე კი სრული ხელმოწერის ჩვენება.
UML-ში ოპერაციებს აქვთ შემდეგი აღნიშვნა:
ოპერაციის სახელი (არგუმენტი: არგუმენტის მონაცემთა ტიპი, არგუმენტი2: არგუმენტი2 მონაცემთა ტიპი,...): დაბრუნების ტიპი
გასათვალისწინებელია ოთხი განსხვავებული ტიპის ოპერაცია:
განხორციელების ოპერაციები;
მართვის ოპერაციები;
წვდომის ოპერაციები;
დამხმარე ოპერაციები.
განხორციელების ოპერაციები
განმახორციელებელი ოპერაციები ახორციელებს ზოგიერთ ბიზნეს ფუნქციას. ასეთი ოპერაციების ნახვა შესაძლებელია ურთიერთქმედების დიაგრამების შესწავლით. ამ ტიპის დიაგრამები ფოკუსირებულია ბიზნეს ფუნქციებზე და დიაგრამაში თითოეული შეტყობინება შეიძლება ასოცირებული იყოს განხორციელების ოპერაციასთან.
თითოეული განხორციელების ოპერაცია უნდა იყოს ადვილად მიკვლევადი შესაბამის მოთხოვნამდე. ეს მიიღწევა სიმულაციის სხვადასხვა ეტაპზე. ოპერაცია მიღებულია ურთიერთქმედების დიაგრამაში მოცემული გზავნილიდან, შეტყობინებები მიღებულია მოვლენების ნაკადის დეტალური აღწერიდან, რომელიც გენერირებულია გამოყენების შემთხვევის მიხედვით, ხოლო ეს უკანასკნელი მოთხოვნილებებზე დაყრდნობით. მთელი ამ ჯაჭვის მიკვლევა საშუალებას გაძლევთ უზრუნველყოთ, რომ თითოეული მოთხოვნა განხორციელდება კოდში და კოდის თითოეული ნაწილი ახორციელებს გარკვეულ მოთხოვნას.
მართვის ოპერაციები
მენეჯერის ოპერაციები მართავენ ობიექტების შექმნას და განადგურებას. ამ კატეგორიას მიეკუთვნება კლასის კონსტრუქტორები და დესტრუქტორები.
წვდომის ოპერაციები
ატრიბუტები, როგორც წესი, პირადი ან დაცულია. თუმცა, სხვა კლასებს ზოგჯერ სჭირდებათ მათი მნიშვნელობების ნახვა ან შეცვლა. ამისათვის არსებობს წვდომის ოპერაციები. ეს მიდგომა შესაძლებელს ხდის კლასში ატრიბუტების უსაფრთხოდ ინკაფსულაციას, მათ დაცვას სხვა კლასებისგან, მაგრამ მაინც იძლევა მათზე კონტროლირებად წვდომას. Get and Set ოპერაციების შექმნა (მნიშვნელობის მიღება და შეცვლა) კლასის თითოეული ატრიბუტისთვის არის სტანდარტი.
დამხმარე ოპერაციები
დამხმარე (დამხმარე ოპერაციები) არის კლასის ის ოპერაციები, რომლებიც აუცილებელია მისი მოვალეობების შესასრულებლად, მაგრამ რომლის შესახებაც სხვა კლასებმა არაფერი უნდა იცოდნენ. ეს არის კერძო და დაცული კლასის ოპერაციები.
ტრანზაქციის იდენტიფიცირებისთვის, გააკეთეთ შემდეგი:
1. მიმდევრობის დიაგრამების და კოოპერატიული დიაგრამების შესწავლა. ამ დიაგრამებში შეტყობინებების უმეტესობა განხორციელების ოპერაციებია. ამრეკლი შეტყობინებები იქნება დამხმარე ოპერაციები.
2. განიხილეთ საკონტროლო ოპერაციები. შეიძლება დაგჭირდეთ კონსტრუქტორების და დესტრუქტორების დამატება.
3. განიხილეთ დაშვების ოპერაციები. თითოეული კლასის ატრიბუტისთვის, რომლებთანაც სხვა კლასებს მოუწევთ მუშაობა, თქვენ უნდა შექმნათ Get and Set ოპერაციები.
4.4.2.7.კავშირები
ურთიერთობა არის სემანტიკური ურთიერთობა კლასებს შორის. ის კლასს აძლევს შესაძლებლობას გაეცნოს სხვა კლასის ატრიბუტებს, ოპერაციებს და ურთიერთობებს. სხვა სიტყვებით რომ ვთქვათ, იმისთვის, რომ ერთმა კლასმა გაუგზავნოს მესიჯი მეორეს თანმიმდევრობით ან კოოპერატიული დიაგრამით, მათ შორის უნდა არსებობდეს კავშირი.
არსებობს ოთხი ტიპის ურთიერთობა, რომელიც შეიძლება დამყარდეს კლასებს შორის: ასოციაციები, დამოკიდებულებები, აგრეგაციები და განზოგადება.
კომუნიკაციის ასოციაცია
ასოციაცია არის სემანტიკური ურთიერთობა კლასებს შორის. ისინი დახატულია კლასის დიაგრამაზე, როგორც ჩვეულებრივი ხაზი.
ბრინჯი. 10. საკომუნიკაციო ასოციაცია
ასოციაციები შეიძლება იყოს ორმხრივი, როგორც მაგალითად, ან ცალმხრივი. UML-ში, ორმხრივი ასოციაციები შედგენილია როგორც მარტივი ხაზი ისრების გარეშე, ან ხაზის ორივე მხარეს ისრებით. ცალმხრივ ასოციაციას აქვს მხოლოდ ერთი ისარი, რომელიც აჩვენებს მის მიმართულებას.
ასოციაციის მიმართულება შეიძლება განისაზღვროს მიმდევრობის დიაგრამების და კოოპერატიული დიაგრამების შესწავლით. თუ მათზე ყველა შეტყობინება იგზავნება მხოლოდ ერთი კლასის მიერ და მიღებულია მხოლოდ მეორე კლასის მიერ, მაგრამ არა პირიქით, ამ კლასებს შორის ცალმხრივი კომუნიკაცია ხდება. თუ ერთი შეტყობინება მაინც იგზავნება საპირისპირო მიმართულებით, ასოციაცია უნდა იყოს ორმხრივი.
ასოციაციები შეიძლება იყოს რეფლექსური. რეფლექსური ასოციაცია ნიშნავს, რომ კლასის ერთი მაგალითი ურთიერთქმედებს იმავე კლასის სხვა ინსტანციებთან.
კომუნიკაციაზე დამოკიდებულება
დამოკიდებულების ურთიერთობები ასევე ასახავს კლასებს შორის ურთიერთობას, მაგრამ ისინი ყოველთვის ცალმხრივია და აჩვენებენ, რომ ერთი კლასი დამოკიდებულია მეორეში გაკეთებულ განმარტებებზე. მაგალითად, კლასი A იყენებს B კლასის მეთოდებს. შემდეგ, როდესაც B კლასი იცვლება, აუცილებელია A კლასში შესაბამისი ცვლილებების შეტანა.
დამოკიდებულება წარმოდგენილია წყვეტილი ხაზით, რომელიც შედგენილია დიაგრამის ორ ელემენტს შორის, ხოლო ელემენტი, რომელიც დამაგრებულია ისრის ბოლოს, არის დამოკიდებული ამ ისრის დასაწყისში დამაგრებულ ელემენტზე.
ბრინჯი. 11. კომუნიკაციაზე დამოკიდებულება
ამ კლასებისთვის კოდის გენერირებისას მათ ახალი ატრიბუტები არ დაემატება. თუმცა, შეიქმნება ენის სპეციფიკური ოპერატორები, რომლებიც საჭიროა კომუნიკაციის მხარდასაჭერად.
კომუნიკაციის აგრეგაცია
აგრეგაციები ასოციაციის უფრო მკაცრი ფორმაა. აგრეგაცია არის კავშირი მთლიანსა და მის ნაწილს შორის. მაგალითად, შეიძლება გქონდეთ მანქანის კლასი, ასევე ძრავის, საბურავების კლასები და სხვა მანქანის ნაწილების კლასები. შედეგად, Car კლასის ობიექტი შედგება Engine კლასის ობიექტისგან, საბურავების ოთხი ობიექტისგან და ა.შ. აგრეგაციები ვიზუალიზდება, როგორც ხაზი რომბით კლასისთვის, რომელიც არის მთელი რიცხვი:
ბრინჯი. 11. კომუნიკაციის აგრეგაცია
მარტივი აგრეგაციის გარდა, UML შემოაქვს აგრეგაციის უფრო ძლიერ ფორმას, რომელსაც კომპოზიცია ეწოდება. შემადგენლობის მიხედვით, საგანი-ნაწილი შეიძლება ეკუთვნოდეს მხოლოდ ერთ მთლიანობას და, უფრო მეტიც, როგორც წესი, ნაწილების სასიცოცხლო ციკლი ემთხვევა მთლიანის ციკლს: ისინი ცხოვრობენ და კვდებიან მასთან ერთად. მთელის ნებისმიერი მოცილება ვრცელდება მის ნაწილებზე.
ეს კასკადური წაშლა ხშირად განიხილება აგრეგაციის განმარტების ნაწილად, მაგრამ ის ყოველთვის იგულისხმება, როდესაც როლის სიმრავლე არის 1..1; მაგალითად, თუ კლიენტს სჭირდება წაშლა, მაშინ ეს წაშლა უნდა გავრცელდეს შეკვეთებზე (და, თავის მხრივ, შეკვეთის ხაზებზე).
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 (Unified Modeling Language - ერთიანი მოდელირების ენა) - გრაფიკული აღწერის ენა პროგრამული უზრუნველყოფის დამუშავების სფეროში ობიექტების მოდელირებისთვის. UML არის ზოგადი ენა, ეს არის ღია სტანდარტი, რომელიც იყენებს გრაფიკულ აღნიშვნას სისტემის აბსტრაქტული მოდელის შესაქმნელად, რომელსაც ეწოდება UML მოდელი. UML შეიქმნა ძირითადად პროგრამული სისტემების განსაზღვრის, ვიზუალიზაციის, დიზაინისა და დოკუმენტაციისთვის. UML არ არის პროგრამირების ენა, მაგრამ კოდის გენერირება შესაძლებელია ინსტრუმენტებში UML მოდელების ინტერპრეტირებული კოდის სახით.ვიკიპედია
კომერციული პროდუქტები
Microsoft Visio
ტიპი: კომერციული პროგრამული უზრუნველყოფა
პოპულარული პროგრამული პროდუქტი Microsoft-ისგან, რომელიც საშუალებას გაძლევთ დახაზოთ მდიდარი დიაგრამები, მათ შორის UML:
2010 წლის ვერსიიდან დაწყებული, შესაძლებელი გახდა დიაგრამების გამოქვეყნება ინტერნეტში (SharePoint + Visio Services):
Visio Viewer- უფასო პროგრამა, რომელიც საშუალებას გაძლევთ ნახოთ ადრე შექმნილი Visio დიაგრამები. შეგიძლიათ ჩამოტვირთოთ %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.
%0A
Microsoft%20Visual%20Studio%202010
%0A%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20ექსპრეს%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).
%0A
%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20მოდელირება,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.
%0A
%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20მიმდევრობა%20დიაგრამა%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.
%0A%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20გამოყენება%20საქმე%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:
%0A%0A%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20ვიზუალიზაცია%20და%20მოდელირება%20ფუნქცია%20პაკეტი%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:
%0A- %D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0 %0A
- %D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20ფენა%20დიაგრამები%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2 %0A
- %D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20ფენა%20დიაგრამები %0A
%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20ვიზუალიზაცია%20და%20მოდელირება%20ფუნქცია%20პაკეტი%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20
IBM Rational Rose
Შესაძლებლობები:
- საქმის დიაგრამის გამოყენება (პრეცედენტების დიაგრამები);
- განლაგების დიაგრამა (ტოპოლოგიის დიაგრამები);
- Statechart დიაგრამა (მდგომარეობის დიაგრამები);
- აქტივობის დიაგრამა (აქტივობის დიაგრამები);
- ურთიერთქმედების დიაგრამა (ურთიერთქმედების დიაგრამები);
- მიმდევრობის დიაგრამა (მოქმედებების თანმიმდევრობის დიაგრამები);
- თანამშრომლობის დიაგრამა (თანამშრომლობის დიაგრამები);
- კლასის დიაგრამა (კლასების დიაგრამები);
- კომპონენტის დიაგრამა (კომპონენტიანი დიაგრამები).
ეკრანის ანაბეჭდები:
ღია კოდის პროგრამები
StarUML
Შესაძლებლობები:
- UML 2.0 მხარდაჭერა
- MDA (მოდელზე ორიენტირებული არქიტექტურა)
- Plug-in Architecture (შეგიძლიათ დაწეროთ COM თავსებადი ენებზე: C++, Delphi, C#, VB, ...)
StarUML იწერება ძირითადად Delphi-ში, მაგრამ კომპონენტები ასევე შეიძლება დაემატოს სხვა ენებს, როგორიცაა C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. ქვემოთ მოცემულია რამდენიმე ეკრანის სურათი.
კლასის დიაგრამა:
გამოყენების საქმის დიაგრამა:
ArgoUML
მხარდაჭერილი სქემები:
- კლასი
- სახელმწიფო
- გამოყენების შემთხვევები
- აქტივობა
- თანამშრომლობა
- განლაგება
- თანმიმდევრობა
Შესაძლებლობები:
- ცხრა UML 1.4 დიაგრამის მხარდაჭერა
- დამოუკიდებელი პლატფორმა (Java 5+)
- UML 1.4 სტანდარტული მეტამოდელი
- XMI მხარდაჭერა
- ექსპორტი GIF, PNG, PS, EPS, PGML და SVG-ში
- ენები: EN, EN-GB, DE, ES, IT, RU, FR, NB, PT, ZH
- OCL მხარდაჭერა
- Forward, Reverse Engineering
სკრინშოტი:
