Posibniki.com.ua Інформатика Корпоративні інформаційні системи 3.4. ТЕХНОЛОГІЯ СТВОРЕННЯ СКЛАДНИХ СИСТЕМ ЗА ДОПОМОГОЮ РЕІНЖИНІРИНГУ


< Попередня  Змiст  Наступна >

3.4. ТЕХНОЛОГІЯ СТВОРЕННЯ СКЛАДНИХ СИСТЕМ ЗА ДОПОМОГОЮ РЕІНЖИНІРИНГУ


Термін «реінжиніринг бізнес-процесів» (BPR — business process reenginee-ring) виник трохи більше двадцяти років тому. 1990 року в одній із перших праць М. Хаммера (президента консалтингової фірми Hammer and Company, що працювала у сфері інформаційних технологій), присвяченій реінжинірингу бізнес-процесів [20], а потім у виданій спільно з Д. Чампі книзі «Реінжиніринг корпорації: Маніфест революції в бізнесі» [13], яка згодом стала бестселером, було проголошено такі гасла:

1. «Реконструюйте роботи не автоматизуючи, а спрощуючи або вилучаючи».

2. «Використовуйте комп’ютери не лише для автоматизації, а й для реконструкції наявних бізнес-процесів».

Пізніше, у 1993 року було введено і сам термін BPR, а замість старого СРІ (Continues Process Improvement) — безперервне поліпшення бізнес-процесів — М. Хаммер запропонував радикальніший спосіб реконструкції управління діяльністю. Мета BPR

— досягти гнучкішої реакції підприємства на зміни вимог споживачів або на прогноз таких змін у разі зниження витрат усіх видів. Поштовхом для запровадження реінжинірингу стали істотні зміни ринкового середовища, в основі яких лежали два головні моменти:

1. Перегляд підходів до виконання ділових операцій з урахуванням досягнутих технологій. Причому переважала орієнтація на самі сучасні технології.

2. Орієнтація не на функціональну структуру організації, а на ділові процесі, в яких вона бере участь під час виробництва необхідного споживачеві продукту.

Саме ці два моменти є головними в переході від традиційної функціональноорієнтованої організації до процесно-орієнтованої, яка підготовлена еволюційним розвитком теорії побудови організацій.

У зазначених працях автори визначають реінжиніринг як фундаментальне переусвідомлення і радикальне перепроектування бізнес-процесів для досягнення істотних поліпшень у таких головних для сучасного бізнесу показниках результативності, як витрати, якість, рівень обслуговування та оперативність.

Під поняттям «фундаментальне переусвідомлення» слід розуміти те, що в процесі здійснення реінжинірингу підприємець має ставити на порядок денний засадові питання стосовно його компанії та характеру її діяльності, а під поняттям «радикальне перепроектування» — передбачати проведення не косметичних змін чи перетасовки наявних систем, а рішучу відмову від усього застарілого.

Основні принципи реінжинірингу такі:

— організовувати досягнення результатів, а не виконання, хоча й важливих завдань;

— доручити виконання процесу тим, хто використовує його результат;

— обробляти інформацію на місцях, де вона виникає;

— поєднувати паралельні роботи в єдине ціле замість інтеграції їхніх результатів;

— переміщення точки прийняття рішення на те місце, де виконується дана робота, за обов’язкового вбудовування контролю в процес;

— одноразове фіксування інформації в джерела її виникнення.

Реінжиніринг породжує безліч змін не лише в бізнес-процесах, а й у багатьох галузях організації, наприклад в інформаційних технологіях. Часто наявна інформаційна система вступає в конфлікт із ситуацією, що виникла на підприємстві: не відповідає певним корпоративним стандартам у сфері передавання та зберігання даних, організації зв’язку з користувачами, призводить до надвисоких накладних витрат тощо. Подібних завдань багато там, де чимало застарілих систем. Цілковита заміна їх лише дорого коштує, а й незрідка просто неможлива, тому виникає проблема реінжинірингу інформаційної системи, тобто надання наявній системі нових якостей, наприклад в Internet/Intraner доступу, підтримки сучасних СУБД, стандартних протоколів доступу до ресурсів і т. д.

Об’єктом реінжинірингу є не організації чи їхні структурні підрозділи, а процеси, зокрема розроблення продукту, продаж, виконання замовлення, обґрунтування тощо.

Після того, як процеси ідентифіковано, з’ясовують питання, які саме з них вимагають реінжинірингу. На цьому етапі формується бажаний образ компанії (фірми), її основні орієнтири і способи їх досягнення та створюється модель реального бізнесу, в якій відтворюється (демонструється) система дій, робіт, за допомогою яких компанія реалізує свої цілі.

Такий підхід потрібен для переусвідомлення і реорганізації бізнес-процесів усередині компанії, але недостатній для розширення реорганізації за межі компанії. Ефект від реорганізації буде суто внутрішнім, тобто охопить одну окрему компанію.

Революційні технологічні зміни та глобальні економічні перетворення в останні десять років змусили компанії розширити рамки реінжинірингу, вийти за межі компанії й інтегрувати власні бізнес-процеси із процесами інших компаній. З’явився новий напрям під назвою Х-реінжиніринг, спрямований на подолання кордонів між організаціями, на використання технологічних процесів для зв’язку компаній одна з одною і підвищення ефективності їхньої діяльності. Х-реінжиніринг — це мистецтво і наука про реорганізацію бізнес-процесів у глобальному середовищі. Центральною організаційною ланкою Х-реінжинірингу є Internet, завдяки якому можна швидко та ефективно збирати, аналізувати й обмінюватися інформацією. Існує чимало інструментальних засобів реалізації реінжинірингу корпоративних інформаційних систем, об’єднаних у так звану групу CASE-засобів. Це системи Rational Rose, Oracle Designer/2000, Oracle Developer/2000, ARIS, CORBA, продукти фірми Logic Works (BPWin i ERWin), Design/IDEF та ін.

Від середини 1990-х років посилюється тенденція розробляти проекти корпоративного рівня на базі компонентно-орієнтованої технології програмування (CBD

— Component Based Development). На ринку інструментальних CASE-засобів підтримки CBD-моделювання і розробки у середині 1990-х домінували чотири фірми: Rational Software, Cayenne, Platinum, Select. Rational Rose належить особливе місце серед CASE-засобів візуального моделювання складних програмних систем, оскільки вона має такі переваги:

— підтримує генерацію коду і зворотне проектування (тобто побудову моделі на базі програмного коду) одночасно для кількох мов, включно з Visual Basic, C++, Java, Power Builder, CORBA, Interface Definition Language (IDL), Data Definition Language для більшості СУБД ERWin-моделі;

— підтримує візуальне об’єктно-орієнтоване моделювання, цілком сумісне з UML (Unified Modeling Language);

— має широкий спектр продуктів-перехідників (Links) фірм, тісно інтегрованих з Rational Rose, і створюваних численними незалежними розробниками інструментальних засобів у рамках програми Rational Rose Link Partner Program;

— зорієнтований на розробників архітектури КІС, менеджерів ІС і програмістів.

Моделювання в Rational Rose 98 проводиться як порівневий спуск від концептуальної моделі до логічної, а потім до фізичної моделі програмного середовища.

Концептуальна модель відображається у вигляді діаграми прецедентів (прецеденти — способи використання системи). Цей тип діаграм використовують для ітераційного циклу загальної постановки задачі спільно із замовником. Діаграми прецедентів слугують підґрунтям досягнення порозуміння між програмістами-професіоналами, які розробляють проект, і замовниками проекту. Усередині кожного прецеденту можна визначити:

— вкладену діаграму прецедентів;

— діаграму взаємодії об’єктів (collaboration diagram);

— діаграму послідовності взаємодії (sequence diagram);

— діаграму класів (class diagram);

— діаграму переходу станів (state diagram).

Логічна модель дає змогу визначити два різні погляди на систему — статичний і динамічний. Статичний підхід виражають діаграми класів (class diagram). Вони слугують основою для генерації програмного коду цільовою мовою програмування.

Динамічний підхід описують два типи діаграм — діаграмами взаємодії об’єктів і діаграмами послідовності взаємодії. Ці діаграми не впливають на генерований програмний код, однак фірми-партнери Rational Software використовують їх у своїх додатках, наприклад для автоматизованого тестування компонентів, розроблених у Rational Rose 98.

Динаміку конкретного класу можна виразити діаграмами переходу станів, які визначають модель кінцевого автомата, що описує поведінку класу. Кожен стан задається своєю вершиною, де визначено вхідні та вихідні стани, а також умови переходу зі стану в стан.

Фізична модель задається компонентною діаграмою (component diagram), яка описує розподіл реалізації класів за модулями, і діаграмою постачань (dep-loyment diagram).

Після побудови першого шару (або наступного) статичної моделі із використанням діаграм класів можна провести генерацію коду цільовою мовою програмування. На рівні коду можна ввести нові уточнюючі класи, змінити атрибути й методи класів моделі, а потім синхронізувати код і модель, виконавши зворотне проектування. Тобто за допомогою модифікованого коду Rational Rose 98 дає змогу побудувати нову логічну модель взаємозв’язку класів між собою. Кількаразове виконання такої процедури називається ітераційним моделюванням (round-trip modeling), воно є основою м’якого й поступового уточнення постановки завдання та узгодження вимог замовника з наявними обчислювальними, фінансовими, часовими ресурсами. CESE-засоби фірми Logic Works складаються із двох пакетів — BPWin для функціонального моделювання й аналізу діяльності підприємства і ERWin для моделювання і створення баз даних довільної складності на підставі діаграм «сутність

—зв’язок».

Пакет BPWin ґрунтується на методології IDEFO (методології функціонального моделювання за допомогою наочної графічної мови) і являє собою сукупність SADT-діаграм, кожна з яких описує окремий процес, розбиваючи його на кроки й підпроцеси.

Нагадаємо, що SADT (Structured Analysis and Design Teqnique)

— графічна мова опису функціональних систем, а назва IDEF (ICAM DEFinition) походить від програми автоматизації промислових підприємств, що мала абревіатуру ICAM (Integrated Computer Aided Manufacturing) і була розроблена департаментом військово-повітряних сил США у 1981 році.

За допомогою з’єднувальних дуг описуються об’єкти, дані та ресурси, необхідні для виконання функцій моделі. Крім того, можна вказати вартість, тривалість і частоту виконання кожного процесу. Ці характеристики в подальшому можуть бути просумовані для обчислення загальної вартості витрат, виявляючи в такий спосіб вузькі місця технологічних ланцюгів і витратні центри. Генерацію звітів за моделлю можна здійснювати у форматах MS Word i MS Excel.

Пакет ERWin використовується під час моделювання даних і підтримує широкий спектр СУБД найрізноманітніших класів — SQL-серверів (Oracle, Infor-mix, Sybase SQL Server, MS SQL Server, Progress, DB2, SQL Base та ін.). Інформаційна модель у системі подається у вигляді діаграм «сутність

— зв’язок», що відображають основні об’єкти предметної галузі та зв’язки між ними. Додатково визначаються атрибути сутностей, характеристики зв’язків, індекси й бізнес-правила, що описують обмеження і закономірності предметної галузі. Після створення ER-діаграми (Entity Relationship) пакет автоматично генерує SQL-код для створення таблиць, індексів та інших об’єктів бази даних. За заданими бізнес-правилами формуються стандартні тригери БД для підтримки цілісності даних.

Пакет може здійснювати реінжиніринг наявних БД, генеруючи ER-діаграми за SQL-текстами. Отже, він цілком підтримує технологію FRE (Forward and reverse engineering)

— пряма зворотна побудова. Послідовність етапів цієї технології має такий вигляд: імпорт із сервера наявної БД, автоматична генерація моделі БД, модифікація моделі, автоматична генерація нової схеми і побудова фізичної БД на тому самому чи на іншому сервері.

Для розроблення клієнтської прикладної частини є спеціальна версія пакета, що забезпечує інтеграцію з такими інструментальними засобами, як SQL Windows, Power Builder, Visual Basic, Delphi.

За допомогою CASE-пакета Design/IDEF (розробник фірма Meta Software) автоматизуються всі етапи проектування складних систем різного призначення: формулювання вимог і цілей проектування, розроблення специфікацій, визначення компонентів і взаємодій між ними, складання документації, перевірка проекту на повноту та суперечність. В основу пакета покладено методологію структурного проектування й аналізу складних систем IDEFO/SADT. Пакет Design/IDEF будує ієрархічні моделі складних систем шляхом декомпозиції їх на блоки, підтримує колективну розробку IDEF-моделі, дає змогу в будь-який момент об’єднувати будь-які підмоделі, створює словник даних для зберігання інформації про функції та структуру даних проекту, формує п’ять типів звітів, що підтримують процес розроблення й аналізу моделей.

Окрім IDEFO пакет підтримує методології моделювання даних IDEF1, IDEF1Х і IDEF/CPN. IDEF1 — методологія моделювання інформаційних потоків усередині системи, яка дає змогу відображати й аналізувати їх структуру і взаємозв’язки. Грунтується на діаграмах «сутність

—зв’язок». IDEF1Х (IDEF1 Extended) — методологія побудови реляційних структур. IDEF1Х належить до типу методологій «сутність

—взаємозв’язок» (ER, Entity — Relationship) і, як правило, використовується для моделювання реляційних баз даних КІС. IDEF/CPN — методологія моделювання динаміки систем, яка ґрунтується на «кольорових» або «розфарбованих» сітках Петрі (CPN — Color Petri Nets). Вона реалізується в системі динамічного моделювання Design/CPN і є компонентою інтегрованої методології розроблення й реінжинірингу складних систем: діаграми, побудовані в Design/IDEF, автоматично імпортуються в Design/CPN і доопрацьовуються вручну для динамічного моделювання й фактичного оцінювання. Design/CPN дає змогу налагоджувати модель для оцінювання її динаміки.

Таке оцінювання дозволяє ефективно розподіляти ресурси й оптимізувати систему, а також перевірити її поведінку в різних режимах.

Пакети Design/IDEF і Design/CPN базуються на відкритій архітектурі Design/ ОА, що дає змогу доповнювати їх модулями, зорієнтованими на конкретне завдання, включно з генерацію коду довільною цільовою мовою.

На особливу увагу заслуговує вихід на ринок прогресивного програмного засобу для аналізу та вдосконалення бізнес-процесів

— ARIS (Architecture of Integrated Information System), розробленого німецькою фірмою IDS Scheer AG. ARIS — це інтегроване середовище для реінжинірингу бізнес-процесів великих підприємств і фірм, що включає сімейство програмних модулів, у межах яких можна скомпонувати оптимальний склад програмної системи, яка повністю забезпечить реалізацію конкретних завдань.

До сімейства ARIS входять модулі: ARIS Toolset — базове інструментальне середовище; ARIS Easy Design — спрощений засіб моделювання; ARIS Simulation

— модуль динамічного імітаційного моделювання; ARIS Link for R/3

— модуль, що забезпечує зв’язок із депозитарієм R/3; ARIS Analyzer for R/3 — модуль перевірки створюваних моделей на відповідність методології SAP; ARIS Promt

— модуль вартісного аналізу: додаткові модулі-інтерфейси, що забезпечують інтеграцію із системами Microsoft Project, ER/Win, Designer/2000, IBM Flowmark, Staffware тощо. ARIS підтримує чотири типи моделей, що відображають різні аспекти досліджуваної системи:

— організаційні моделі, — представляють структуру системи — ієрархію підрозділів підприємства, посад і конкретних осіб, багатоманіття зв’язків між ними, а також територіальну прив’язку структурних підрозділів;

— функціональні моделі, що містять ієрархію цілей апарату управління, дерев функцій, необхідних для досягнення поставлених цілей;

— інформаційні моделі — відображають структуру інформаційного забезпечення, необхідного для реалізації всієї сукупності функцій системи;

— моделі управління — відображають комплексний погляд на реалізацію ділових процесів у межах системи.

Графічно такий підхід подано на рис. 3.4.

Рис. 3.4. Взаємозв’язок типів моделей, використовуваних в ARIS

Рис. 3.4. Взаємозв’язок типів моделей, використовуваних в ARIS

У рамках кожного із перелічених типів створюються моделі різних видів, що відображають відповідні аспекти досліджуваної системи. ARIS підтримує значну кількість методів моделювання, а саме: діаграми Гантта, Unified Modeling Language (UML), Object Modeling Technique (OMT) та ін. Остання версія ARIS підтримує понад 120 методів моделювання [44].

Перевагою програмної системи ARIS є те, що в процесі аналізу кожного структурного елементу бізнесової системи можна приділити особливу увагу, не відволікаючись на її зв’язок з іншими елементами. І тільки після детального опрацювання всіх аспектів можна братися до побудови інтегрованої моделі, що відображає всі наявні зв’язки між усіма елементами системи.

Крім того, ARIS не накладає обмежень на послідовність опрацювання перелічених вище чотирьох моделей. Процес аналізу та проектування можна розпочинати з будь-якої моделі залежно від конкретних умов і цілей, обраних розробником. Зручні й ефективні засоби моделювання та навігації, а також підтримка повноцінної роботи багатьох користувачів дають можливість одночасно працювати над усіма типами моделей. Іншою особливістю методології ARIS, що забезпечує цілісність розроблюваної системи, є використання різних рівнів опису життєвого циклу системи. У ARIS Toolset використовують триразову модель життєвого циклу, тобто кожна з перелічених моделей має три рівні подання.

1. Рівень визначення вимог. На цьому рівні моделювання описують вимоги до системи: що має робити система, як вона організована, які ділові процеси в ній присутні, які дані при цьому використовуються тощо.

2. Рівень проектної специфікації. Цей рівень відповідає концепції інформаційної системи і визначає основні шляхи реалізації подання на другому етапі вимог.

3. Рівень опису реалізації проекту. На цьому етапі життєвого циклу створення інформаційної системи відбувається перетворення специфікацій у фізичний опис конкретних програмних і технічних засобів. Це завершальний етап проектування системи, за яким іде етап фізичної реалізації (програмування). Рівень опису реалізації відповідає за формування документів, на підставі яких можна забезпечити процес розроблення програмних модулів (або підбору готових програмних продуктів, що відповідають поставленим вимогам), і вибір технічних засобів реалізації систем.

Графічно поділ на рівні в ARIS унаочнено на рис. 3.5.

Після побудови статичної моделі системи, яка описує її структуру, принципи функціонування та дані, які при цьому використовують, виникає потреба оцінити поведінку системи в часі залежно від даних, що подаються на вхід. Це завдання виконують за допомогою модуля ARIS Simulation. У результаті динамічного аналізу ділових процесів можуть бути виявлені вузькі місця, наприклад критичні ситуації, що виникають через брак ресурсів, або низький рівень завантаження ресурсів, тривалість простоїв у процесах за браку ресурсів тощо. Імітація виявляє виникнення незапланованого часу очікування в деяких точках процесу і, таким чином, дозволяє виявити брак запланованих ресурсів, наприклад, людських. У такому разі функція процесу не може бути виконана, бо всі призначені співробітники зайняті виконанням інших функцій. Можна відстежувати й коригувати точки синхронізації в часі, коли кілька операцій треба

закінчити, щоб можна було почати виконання наступної операції. Таке коригування можна провести збільшенням кількості виконавців безпосередньо перед тим моментом, коли може виникнути проблема, або шляхом перенесення часу виконання функції.

Рис. 3.5. Рівні подання моделей в ARIS

Рис. 3.5. Рівні подання моделей в ARIS

Ще одним важливим аспектом при моделюванні стає аналіз фінансових витрат, необхідних для забезпечення нормальної життєдіяльності системи. Цю царину вартісного аналізу здійснюють за допомогою модуля ARIS Promt. Він уможливлює управління вартістю, що не залежить від поділу організації на структурні підрозділи, диференційоване оцінювання накладних витрат, управління додатковими процесами, та аналіз інформації про витрати.

РЕЗЮМЕ

Наповнення предметної частини КІС може істотно змінюватися залежно від профілю діяльності підприємства, масштабів організації та обсягів інформаційних робіт. Із їхнім збільшенням стає актуальним упровадження спеціалізованих програмних засобів, здатних підтримувати чималі за обсягом бази і сховища даних, електронні архіви змішаної документації із забезпеченням необхідного рівня надійності й безпеки збереження інформації.

До базових стандартів управління бізнесом належать MPS, SIC, MRP, MRPII, ERP, CSRP. Але поряд з цим структуру КІС визначають технології, що реалізують цей функціонал. Сучасні технології побудови КІС спираються здебільшого на клієнт-серверні архітектури. Існують три топологічні моделі інформаційних систем: мала (файл-серверна), середня (дворівнева клієнт-серверна на базі моделей RDA i DBS), велика (трирівнева клієнт-серверна на базі AS-моделі).

Щоб забезпечити прозорий доступ користувачів і програм до віддалених даних у мережі, що поєднує різнорідні комп’ютери, комунікаційний сервер має підтримувати якнайпоширеніший діапазон мережевих протоколів (TCP/IP, DECnet, SNA, SPX/IPX, NetBIOS, Apple Talk та ін.).

Взаємодія прикладного компонента з ядром СУБД неможлива без стандартного засобу спілкування. Запити, що їх надсилає прикладна програма до ядра СУБД, мають бути одинаково зрозумілими для обох сторін. Для цього їх треба сформулювати спеціальною мовою. Такою мовою в сучасних СУБД є мова SQL. Тому уніфікація інтерфейсу мовою SQL є важливою перевагою клієнтсерверної технології.

У КІС використовують три основні варіанти Web-доступу до баз даних.

1. Одноразове або періодичне перетворення вмісту БД на статичні документи.

2. Динамічне створення гіпертекстових документів на основі вмісту БД.

3. Створення інформаційного сховища на базі високопродуктивної СУБД із мовою запитів SQL.

Часто наявна інформаційна система вступає в конфлікт із ситуацією, що виникла на підприємстві: не відповідає певним корпоративним стандартам у сфері передання та зберігання даних, організації зв’язку з користувачами, призводить до надвисоких накладних витрат тощо. Подібних завдань багато там, чимало застарілих систем. Цілковита заміна їх не лише дорого коштує, а й нерідко неможлива, відтак, виникає проблема реінжинірингу інформаційної системи.

Основні принципи реінжинірингу такі:

— організовувати досягнення результатів, а не виконання окремих, хоча й важливих завдань;

— доручити виконання процесу тим, хто використовує його результат;

— обробляти інформацію на місцях, де вона виникає;

— об’єднувати паралельні роботи в єдине ціле замість інтеграції їхніх результатів;

— переміщення точки прийняття рішення на те місце, де виконується дана робота, за обов’язкового вбудовування контролю у процес;

— одноразове фіксування інформації у джерела її виникнення.

ТЕРМІНИ І ПОНЯТТЯ

Основні архітектури для побудови сервера (процесора) бази даних — з кількома процесами і багатопотокова.

Архітектура з кількома процесами характеризується тим, що кілька екземплярів виконуваного файлу, працюють одночасно.

Багатопотокова архітектура використовує лише один виконуваний файл, з кількома потоками виконання. Data Access Objects (DAO)

— доступ до локальних баз даних. Remote Data Objects (RDO) — доступ до віддалених баз даних.

Доступ до локальних і віддалених даних

— ActiveX Data Objects (ADO).

Брандмауер — програмна система чи комбінація систем, організаційно оформлена на окремому або на кількох комп’ютерах, яка вможливлює розподіл мереж на дві та більше частин і реалізацію набору правил, що визначають умови проходження пакетів з однієї частини в іншу.

ЗАПИТАННЯ ДЛЯ ПЕРЕВІРКИ ЗНАНЬ

Поняття базисної технології у КІС.

Сутність технології доступу, зберігання та адміністрування даних у КІС.

Організація електронного документообігу в КІС Сутність інтелектуального аналізу в КІС.

Технологія створення складних систем за посередництва реінжинірингу.

ЗАВДАННЯ ДЛЯ ІНДИВІДУАЛЬНОЇ РОБОТИ

Розробити схему перевантаження даних з основних БД до сховища даних. Розробити схему оброблення запитів у сховищі даних.

Спроектувати модель електронного документообігу для програмної системи «БОСС». РОЗДІЛ 4


< Попередня  Змiст  Наступна >
Iншi роздiли:
4.2. МОДЕЛІ ТИРАЖУВАННЯ ДАНИХ
4.3. СХЕМИ ТИРАЖУВАННЯ ДАНИХ
РОЗДІЛ 5 КОРПОРАТИВНІ СХОВИЩА ДАНИХ
5.2. АРХІТЕКТУРА ІНФОРМАЦІЙНИХ СХОВИЩ
5.3. АДМІНІСТРУВАННЯ ІНФОРМАЦІЙНИХ СХОВИЩ
Дисциплiни

Медичний довідник новиниКулінарний довідникАнглійська моваБанківська справаБухгалтерський облікЕкономікаМікроекономікаМакроекономікаЕтика та естетикаІнформатикаІсторіяМаркетингМенеджментПолітологіяПравоСтатистикаФілософіяФінанси

Бібліотека підручників та статтей Posibniki (2022)