SE

SE#6.1 საინფორმაციო სისტემის არქიტექტურა (Software Architectural design)

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

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

სისტემის არქიტექტურა (System Architecture) შესაძლებელია წარმოდგენილი იქნეს, ორი სახის დეტალიზაციით:

  1. Architecture in the small – სისტემის ცალკეული კომპონენტების ურთიერთქმედების არქიტექტურა.  მისი ამოცანაა სისტემის კომპონენტების დეკომპოზიცია მის შემადგენელ ნაწილებად;
  2. Architecture in the large – მთლიანი სისტემის სხვა სისტემებთან ურთიერთქმედების არქიტექტურა. მისი ამოცანაა მთლიანი სისტემის სხვა სისტემებთან და მათ კომპონენტებთან ურთიერთობის სქემების აღწერა;

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

  • Stakeholder communication: სისტემის არქიტექტურა მოსახერხებელი ფორმაა, სისტემის მფლობელებთან და მის შექმნაში ჩართულ მხარეებთან კომუნიკაციისთვის;
  • System analysis:  კარგად შედგენილი სისტემის არქიტექტურის დოკუმენტი, საშუალებას აძლევს ბიზნეს ანალიტიკოსს, მოიპოვოს და ანალიზი გაუკეთოს  სისტემის არაფუნქციონალურ მოთხოვნებს;
  • Large-scale reuse: ერთხელ დოკუმენტირებული და განხორციელებული არქიტექტურა, შესაძლებელი მრავალჯერადად იქნეს გამოყენებული, კომპლექსურ სისტემებში და სხვა პროექტებში.

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

 სისტემის არქიტექტურის სტილი, შეიძლება განსაზღვროს, სისტემის შემდეგმა არაფუნქციონალურმა მოთხოვნებმა (non-functional system requirements):
  • Performance:  სისტემის წარმადობის უზრუნველყოფისთვის,  კრიტიკული ობიექტების ლოკალიზება და კომუნიკაციის მინიმიზირება;
  • Security: სისტემის უსაფრთხოების უზრუნველსაყოფად, გამოყენებული იქნეს მრავალდონიანი არქიტექტურა, რომელშიც კრიტიკული ობიექტები განთავსებულია მაქსიმალურად დაბალ დონეზე;
  • Safety: სენსიტიური კომპონენტების დაცვისთვის, მათი დაშლა მცირე კომპონენტებად და მათი სხვადასხვა დონის სივრცეებში ლოკალიზება;
  • Availability: სისტემის მდგრადობისთვის,  სათადარიგო მოდულების დაგეგმვა და მათი საშუალებით პროცესების უზწყვეტობის უზრუნველყოფა;
  • Maintainability:  სისტემის მომსახურეობის გამატივების მიზნით , მოდულური, ადვილად ჩანაცვლებადი კომპონენტების შექმნა.

The particular architectural style should depend on the non-functional system requirements:

  • Performance: localize critical operations and minimize communications. Use large rather than fine-grain components –
  • Security: use a layered architecture with critical assets in the inner layers.
  • Safety: localize safety-critical features in a small number of sub-systems.
  • Availability: include redundant components and mechanisms for fault tolerance.
  • Maintainability: use fine-grain, replaceable components. #1

არქიტექტურული ხედვები და პერსპექტივები – Architectural Views

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

 

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

  1. A logical view, which shows the key abstractions in the system as objects or object classes. – სისტემის ლოგიკური პერსპექტივა, რომლის დროსაც ხორციელდება სისტემის  ძირითადი კომპონენტების და მისი ქვეკომპონენტების დეკომპოზიცია;
  2. A process view, which shows how, at run-time, the system is composed of interacting processes. – სისტემის შემადგენელ კომპონენტებს შორის,  ურთიერთქმედების პროცესების მიმდინარეობის აღწერა;
  3. A development view, which shows how the software is decomposed for development. – გამოვლენილი კომპონენტების მიხედვით, საინფორმაციო  სისტემის შექმნის პროცესის თანმიმდევრობა;
  4. A physical view, which shows the system hardware and how software components are distributed across the processors in the system. – სისტემის პროგრამული უზრუნველყოფის განაწილება აპარატულ კომპონენტების მიხედვით;
  5. Related using use cases or scenarios (+1). –  სისტემაში მიმდინარე პროცესების შესაბამისი სცენარების (Use Cases) აღწერა და არქიტექტურული დეკომპოზიცია;

4+1 არქიტექტურული მოდელი

სისტემის არქიტექტურული დიზაინის მნიშვნელოვანი პრინციპები – Key Architectural Design Principles

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

  1. Separation of concerns – ფუნქციების განცალკევება – სისტემის კომპონენტებად დაშლის დროს,  მაქსიმალურად ეცადეთ, ცალკეული კომპონენტების ფუნქციონალი არ იმეორებდენ და ფარავდენ სხვა კომპონენტების ფუნქციონალს. მნიშვნელოვანია მათ შორის კომუნიკაციის დროს,  ცალსახად გაიმიჯნოს სამოქმედო არეალი და გადანაწილდეს ფუნქციები.  ერთი კომპონენტის დაზიანებამ, არ უნდა გამოიწვიოს სხვა კომპონენტების დაზიანება.
  2. Single Responsibility principle -პასუხისმგებლობის განაწილების პრინციპი. სისტემის ყოველი კომპონენტის პასუხისმგებელი უნდა იყოს, კონკრეტულ ფუნქციების შესრულებაზე, მისი დუბლირება არ ხდება სხვა კომპონენტებში. სისტემის სხვადასხვა კომპონენტები ერთიდაიგივე მოზნებს არ უნდა ასრულებდნენ, სხვადასხვა არქიტექტურულ შრეზე და განსხვავებული ლოგიკით.
  3. The principle of Least Knowledge (also known as the Law of Demeter or LoD). – შემოსაზღვრული ცნობიერების პრინციპი – სისტემის ცალკეულმა კომპონენტმა არ უნდა იცოდეს სხვა კომპონენტში მიმდინარე პროცესების შესახებ;
  4. Don’t repeat yourself (DRY) –  ფუნქციონალის დუბლირების შეზღუდვის პრინციპი – კონკრეტული ფუნქციონალი უნდა აღიწეროს ერთხელ და მას უნდა ასრულებდეს ერთი, განსაზღვრული სისტემური კომპონენტი;
  5. Minimize upfront design. This principle is sometimes known as YAGNI (“You ain’t gonna need it”). –  მოახდინეთ მხოლოდ იმ ფუნქციების არქიტექტურული დიზაინის შექმნა, რომლებიც აუცილებელია კონკრეტული მიზნების მისაღწევად. მიზნების გაფართოების კვალდაკვალ მოახდინეთ სისტემის არქიტექტურული დიზაინის მოდიფიცირება.

პრაქტიკაში არსებობს შემდეგი ტიპის სისტემური არქიტექტურის მოდელები  (#)

  1. Layered architecture – იერარქიულ დონეებზე განაწილებული არქიტექტურა;
  2. Repository architecture – ცენტრალურ სამონაცემთა სანახზე დაფუძნებული არქიტექტურა;
  3. Client-server architecture – ცენტრალიზებულ მონაცემთა დამუშავების ცენტრის არქიტექტურა;
  4. Pipe and filter architecture – ინფორმაციული  ნაკადების  დამუშავების არქიტექტუარა;
  5. Application architectures – საინფორმაციო სიტემების კომპონენტების არქიტექტურა.

Layered Architecture

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

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

  1. მაღალ დონეზე (Presentation/user Tier), თავსდება სისტემის მომხმარებელთან ან სხვა სისტემებთან ურთიერთობის სისტემური კომპონენტები:
  2. შუა დონეზე (Logic Tier),  თავსდება სისტემის ფუნქციონირების, ბიზნეს ლოგიკის წამმართველი და მონაცემთა წყაროებთან კავშირის კომპონენტები;
  3. დაბალ დონეზე (Data Tier) თავსდება, მონაცემთა წყაროები, ინფორმაციული სანახები და საბაზო (Core) ოპერაციული სისტემები.

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

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

  1. ყველაზე მაღალ დონეზე (Presentation/user Layer), თავსდება სისტემის მომხმარებელთან ან სხვა სისტემებთან ურთიერთობის, ინტერფეისული კომპონენტები:
  2. მომდევნო, სერვისების დონეზე (Service Layer), თავსდება სისტემის მომხმარებელთან,  სხვა სისტემებთან, სისტემის ბიზნეს ლოგიკის კომპონენტებთან,  კავშირის უზრუნველყოფის სისტემური კომპონენტები;
  3. მომდევნო ბიზნეს ოპერირების დონეზე  (The Business Layer) თავსდება, სისტემის ფუნქციონირების, ბიზნეს ლოგიკის წამმართველი,  სერვისების და მონაცემთა შრესთან ურთიერთობის კომპონენტები;
  4. ყველაზე დაბალ დონეზე (Bottom / Data Layer) თავსდება, მონაცემთა წყაროებთან, ინფორმაციული სანახებთან, სისტემის სერვისული კომპონენტებთან და საბაზო (Core) ოპერაციული სისტემებთან ურთიერთობის კომპონენტები.
Ee658124.b8220f0d-f76a-40d6-8b1b-5279f7cdcee9(en-us,PandP.10).png

პროგრამული სისტემის ზოგადი არქიტექტურა

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

სისტემის არქიტექტურა უნდა ასახავდეს მთლიანი სიტემის ფუნქციონირებას და მისი კომპონენტების მოქმედების არეალს. რადგან ზემოთ მაგალითში,  Presentation Layer (UI), Services Layer, Business Layer  და Data Layer არეები წარმოადგენენ სისტემური იერარქიის განსხვავებულ შრეებს, მათი კომპონენტები უნდა ასრულებდნენ შრის შესაბამის და არ უნდა ასროლებდნენ სხვა შრეების ამოცანებს. მაგალითად Presentation Layer (UI)   შრე არ უნდა შეიცავდეს  სისტემურ კომპონენტებს, რომლებიც პირდაპირ უკავშირდებიან მონაცემთა სანახების კომპონენტებს Data Layer-ში, Business Layer – შრის ჩართვის გარეშე.

Repository architecture

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

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

Client-server architecture

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

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

Client-Server  სისტემური არქიტექტურა

Pipe and filter architecture

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

ინფორმაციური ნაკადების არქიტექტურა

Application architectures

Application architectures – საინფორმაციო სიტემების კომპონენტების არქიტექტურა. საინფორმაციო სისტემები შექმნის ძირითადი მიზანია, სისტემის მომავალი მფლობელის მოზნების და საჭიროებების (User Requirements) დაკმაყოფილება.

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

ზოგადი აპლიკაციის არქიტექტურა (A generic application architecture) – წარმოადგენს, სისტემის არქიტექტურის დიზაინს, რომელიც გამოიყენება  მსგავსი ტიპის ბიზნეს ამოცანებისთვის. მათი გამოყენება სასარგებლოა შემდეგ მოცემულობებში:

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

ზოგადი აპლიკაციის არქიტექტურების მაგალითებია:

  • Data processing applications – მონაცემთა დამუშავების სისტემები;
  • Transaction processing applications – ფინანსური ნაკადების დამუსავების სისტემები;
  • Event processing systems – ხდომილებების მონიტორინგის და მათზე რეაგირების სიტემები;
  • Operation Systems – ინფორმაციული სისტემების მართვის საოპერაციო სიტემები;
  • და აშ.

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

  • Architectural Design #1, #2. #3
  • Software Architecture and Design  – MSDN #1
  • How To Develop Architectural Concepts #1, #2
  • Application Modelling #1, #2
  • ERP (Enterprise Resource Planning) სისტემები #1, #2, #3

დავალებები:

  1. ჩამოთვალეთ, ერთი და იგივე გარემოში, ერთი და იგივე სისტემური არქიტექტურის მქონე სისტემის  ან კომპონენტის 3 მაგალითი.  გააკეთეთ მათი გამოყენების დადებითი და უარყოფითი მხარეების ანალიზი;
  2. ჩამოთვალეთ, განსხვავებულ გარემოში, ერთი და იგივე სისტემური არქიტექტურის მქონე სისტემის  ან კომპონენტის 3 მაგალითი.  გააკეთეთ მათი გამოყენების დადებითი და უარყოფითი მხარეების ანალიზი;
  3. რა შესაძლებლობებს გვაძლევს სისტემის ზუსტი არქიტექტურის შექმნა?
  4. შექმენით შემდეგი სისტემების არქიტექტურული დიზაინი:
    • 3.1 ელექტრონული წიგნების მაღაზია;
    • 3.2 ელექტრონული საბანკო ოფისი;
    • 3.3 დისტანციური სერვისი, ID ბარათით, სამგზავრო დოკუმენტის (ბიომეტრიული პასპორტი) მისაღებად;
    • 3.3 დისტანციური სერვისი, საქართველოში მოკლევადიანი ტურისტული ვიზის მისაღებად;
  5. ჩამოთვალეთ თქვენთვის ცნობილი საინფორმაციო სისტემის არქიტექტურული დიზაინის შექმნის ფუნდამენტური პრინციპები;
  6. რა განსხვავებას ხედავთ, Separation of concerns და Single Responsibility principle – შორის ?
  7. სტსტიაში მოხსენებული, სისტემური არქიტექტურის 5 ტიპისთვის, აღწერეთ სისტემური არტიტექტურის:
    • აღწერა (Description);
    • დანიშნულება და გამოყენების არეალი (When used);
    • დადებითი მხარე (Advantages);
    • უარყოფითი მხარე (Disadvantages).
Advertisements

4 thoughts on “SE#6.1 საინფორმაციო სისტემის არქიტექტურა (Software Architectural design)

  1. Pingback: SE#4.2 Requirements Engineering process | Innovation Times

  2. Pingback: SE#8.1 Software Testing – სისტემის ტესტირება | The Digital Times

  3. Pingback: SE#1.1 Introduction to Software Engineering | IN@TIMES

  4. Pingback: SE#9.1 საინფორმაციო სისტემების განვითარება (Software evolution) | IN@TIMES

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s