BA #1.3 ოპერირების სცენარების მოდელირება (Use Case Modeling)

Reference: Sommerville, Software Engineering, 10 ed., Chapter 4

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

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

ოპერირების სცენარები საინფორმაციო სისტემის მოდელირებისთვის

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

სისტემური მოთხოვნების ფორმირების მატრიცა Requirements Formation Matrix

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

გზა მიზნიდან განხორციელებამდე From goal to Implementation Roadmap

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

Use Case დიაგრამები

Use case დიაგრამა წარმოადგენს, ქცევითი ტიპის (behavioral)  UML  დიაგრამის სახეს და გამოიყენება სისტემების აღწერისათვის.  მათი დახმარებით შესაძლებელი ხდება გამოვლინდეს მომხმარებლების სიტემასთან ურთიერთქმედების როლები და მათი სისტემასთან ურთიერთობის სცენარები. #1.

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

Use case დიაგრამები შედგება 4 ობიექტისგან:

1. Actor –  სისტემის მონაწილის როლი;
2. Use case – სისტემის Actoris სისტემასთან ურთიერთმოქმედების სცენარი;
3. System –  სისტემა;
4. System Subject / Package – სისტემის კომპონენტი, მოქცეული კონკრეტული საზღვრებში, და რომლიგანაც შედგება მთელი სისტემა;

აღსანიშნავია, რომ Use Case დიაგრამა (Use Case Diagram) და  Use Case  სცენარი (Use Case Scenario) , არსებითათ განსხვავებული ცნებებია, use case დიაგრამა არის აქტივობების ერთობლიობა, რომელებიც დადგენილ საზღვრებში უნდა განხორციელდეს სისტემის მომხმარებლების მიზნების მისაღწევად. ბუნებრივის  მათი რაოდენობა სისტემის სხვადასხვა მომხმარებლისთვის, დროის განსხვავებულ მონაკვეთში განსხვავებული იქნება. თავის მხრივ Use Case  სცენარი, არის ერთი განსხვავებული გზა,  Use Case დიაგრამაში.

ზოგადად უნდა ითქვას, რომ, სისტემის მონაწილე – (System Shakehoder),  არის ნებისმიერი პერსონა რომელსაც შეხება ააქვს სისტემასთან.  სისტემის მომხმარებელი – (System User) – არის პერსონა რომელიც,  ურთიერთქმედებს სისტემასთან, სისტემის აქტორი – System Actor – არის სისტემასთან ურთიერთობის როლი, რომლისთვისაც იწერება შესაბამისი სცენარი –  (Uer Case სცენარი) მისი მიზნის მისაღწევად. იგი შეიძლება შეასრულოს სისტემის ნებისმიერმა უფლებამოსილმა პირმა.

Use Case დიაგრამების შექმნის დროს პირველი ნაბიჯია,  დადგენილ სამოქმედო არეალში –  (System Scope), როლების  (Actor) და მათი მიზნების გამოვლენა, რის შემდეგადაც ხდება შემდეგ თვითეული Actoris მიზნის მისაღწევად, შესაბამისი  სცენარის (User Case Scenario) შემუშავება.

დიაგრამაზე ქვემოთ, “ტურისტი” და “ტუროპერატორი” – არიან სისტემის Actor-ები.  თავის მხრივ ტურისტს, სისტემის აღწერილ საზღვრებში – “ტურის ელექტრონული დაჯავშნის სისტემა” ააქვს სამი მიზანი:

1. ტურის შერჩევა – რომელსაც აღწევს  UseCase სცენარით “ტურის შერჩევა”;
2. ტურის შედარება – რომელსაც აღწევს  UseCase სცენარით “ტურების შედარება”;
3. ტურის შესახებ ინფორმაციის დაზუსტება – რომელსაც აღწევს  UseCase სცენარით “ტურის შესახებ ინფორმაციის დაზუსტება”

ტუროპერატორს კი აქვს ორი მიზანი:

1. ტურების შექმნა და განახლება – რომელსაც აღწევს  UseCase სცენარით “ტურების შექმნა და განახლება”;
2. ტურის შესახებ ინფორმაციის დაზუსტება – რომელსაც აღწევს  UseCase სცენარით “ტურის შესახებ ინფორმაციის დაზუსტება”

სისტემის საზღვრები (Subject / Package)  და მომხმარებლების (Actors) ქცევის სცენარები (UseCases)

სისტემების ინჟინერიის პროცესში, ხშირად ხდება საჭირო, Actor – ების გაერთიანება საერთო როლის მახასიათებლის მიხედვით, რომელსაც ეწოდება გენერალიზაციის პროცესი –  Actors Generalization, როგორც მაგალითში:

Actors Generalization

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

Use Case სცენარების შექმნის დროს, შესაძლებელია გამოიკვეთოს ისეთი ფუნქციონალური შესაძლებლობები, რომლების ხშირად მეორდება სისტემის სხავადასხვა სცენარებში, ამ შემთხვევაში ხდება ასეთი მონაკვეთების განცალკევება დამოუკიდებელ სცენარებად. მათი გამოძახება შესაძლებელია სხვა სცენარებიდა. ამას ქვია Include დამოკიდებულება, ქვემოთ მაგალითში System Maintenance სცენარი თავისი საჭიროებებისთის იყენებს დამოუკიდებელ სცენარებს – System Reporting და System Shutdown რომლებიც მასთან დაკავშირებულია Include დამოკიდებულებით.

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

Use Case სტრუქტურა

Use Case დიაგრამის დოკუმენტირების დროს უნდა გავითვალისწინოთ, რომ იგი უნდა შეიცავდეს მინუმუმ შემდეგ კომპონენტებს:

1. Name of The Use Case – Use Case -ს სახელი;
2. Use Case short Overview – Use Case -ს მოკლე აღწერა;
3. list of Actors – პროცესის მონაწილეების როლები, მათგანი Primary Actor – არის ძირითადი როლი, რომელის მიზნის მიღწევას ემსახურება Use Case დიაგრამა, სხვები შეიძლება იყვნენ სისტემის დამხმარე მონაწილეები;
4. PreCondition – სისტემის მდგომარეობა, სცენარების დაწყების წინ;
5. PostCondition – სისტემის მდგომარეობა, სცენარების დასრულების შემდეგ;
6. List of the Scenarios – Use Case – ში, Primary  Actor -ის მიზნების მისაღწევად სისტემაში აღწერილი ყველა შესაძლო სცენარი;

Use Case მაგალითი (#1)

Use Case დიაგრამის აღწერა

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

Use Case -ის ნიმუში და დოკუმენტის შაბლონი #1 #2

Use Case სცენარების შემუშავების ოპტიმალური გზა შემდეგია:

1. პირველად იქმნება Main Sucess Scenario (Happy Path) – სცენარი რომლის საშუალებით მიიღწევა Actor-ის მიზნები ყველანაირი დაბრკოლებების გარეშე;
2. შემდეგ იქმნება – Alternative Scenario – სცენარები, რომელთა საშუალებით კვლავ შესაძლებელია მიღწეული იქნეს Actor-ის მიზნები, მხოლოდ გარკვეული დამატებითი გზებით;
3. საბოლოოდ იქმნება – Exeption – სცენარი რომლის განვითარების შედეგად, არსებულ გარემო პირობებში, შეუძლებელი ხდება Actor-ის მიზნების მიღწევა;

Use Case სცენარები და მათი დანიშნულება

პრაქტიკაში სისტემის ფუნქციონირების თანმიმდევრობის დიაგრამები (Sequence diagrams  (#1)) ხშირად გამოიყენება Use Case სცენარების დაზუსტებისთვის. მათი საშუალებით ზუსტდება Primary Actor-ის ურთიერთობის დინამიკა სისტემასთან და სისტემის მონაწილეებთან, ნათლად იკვეთებს ძირითადი და ალტერნატიული სცენარების მიმდინარეობა:

Use Case დიაგრამების დეტალიზაცია

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

სტატიის ბოლოს ავღნიშნავთ, რომ Use Case დიაგრამების შედგენის დროს, მათი აღწერის დეტალიზაციის დონის აღსანიშნავად, გამოყენებული იქნეს შემდეგი გრაფიკული გამოსახულებები  (#1) :

დეტალიზაციის დონე და სიმბოლოები

საკითხავი მასალა:

• IIBA BABOK® Guide v3 #1, #2
• The PMI Guide to Business Analysis – First Edition #1
• Agile Extension to the BABOK Guide – Agile Alliance,
• Requirements Engineering  #1, #2
• Requirements Analysis #2
• What Are Use Case Scenarios? #1
• Use Cases and System Modeling #1, #2,#3, #4
• Use Cases & Requirements Elicitation #1, #2, #3
• Use Case Diagram Examples #1, #2, #3, #4,  #5, #6, #7, #8, #9, #10
• UML 2 Use Case Diagrams  #1, #2, #3, #4
• BPMN Online Training #1
• UML Use Case Diagram Examples – #1, #2
• Mobile app concepts and use cases  #1 #2
• UML Tutorial – #1
• Writting User Cases –  #1, #2, #3

კითხვები:

1. რას წარმოადგენს Use case დიაგრამა?;
2. რისთვის გამოიყენება Use case დიაგრამა?;
3. აღწერეთ სტატიაში აღწერილი გზა მიზნიდან მის განხორციელებამდე? რა მოსაზრებებიგაქვთ ამ თემაზე?;
4. რას წარმოადგენს Actor – Use case დიაგრამაში, რა არის მისი დანიშნულება?;
5. რას ნიშნავს გენერალიზაციის პროცესი –  Actors Generalization?;
6. რას ნიშნავს შცენარი A იყენებს სცენარ B-ს Include დამოკიდებულებით?;
7. რას ნიშნავს შცენარი A იყენებს სცენარ B-ს Extend დამოკიდებულებით?;
8. Use Case სცენარში რას ნიშნავს  Main Sucess Scenario (Happy Path)?;
9. Use Case სცენარში რას ნიშნავს Alternative Scenario ?;
10. Use Case სცენარში რას ნიშნავს Exeption ?;
11. რა რანიშნულება ააქვსთ სისტემის ფუნქციონირების თანმიმდევრობის დიაგრამებს (Sequence diagrams  (#1)), სისტემის  სცენარების შემუშავებაში ?

Ch4 req eng from software-engineering-book