Спросить
Войти
https://orcid.org/0000-0002-2552-2839 https://orcid.org/0000-0001-5568-7629 https://orcid.org/0000-0002-4133-722X
УДК 004.02
С.В. ГРИБКОВ*, В.А. ЛИТВИНОВ**, Г.В. ОЛ1ЙНИК*
Нацюнальний унiверситет харчових технологiй, м. Кшв, Украша 1нститут проблем математичних машин i систем НАН Украши, м. Кшв, Украша
Анотаця. Одним i3 важливих завдань при виршенш проблеми створення мереж1 Ситуацтних центр1в (СЦ) оргамв державног влади Украгни е вiдпрацювання типових ршень у рiзних сферах проблематики проектування, впровадження i функщонування СЦ. Метою статтi е спроба част-кового заповнення деяких наявних прогалин у вiдношеннi методологiчного та тструментального забезпечення реалiзацiг програмного комплексу СЦ. Вiдзначаеться беззаперечна доцтьмсть за-стосування ШерацШного (еволюцтного) тдходу до процесу проектування СЦ з урахуванням реа-льних втчизняних умов та ризиюв. Як можлива основа прототипування СЦрозглядаються сучас-rn ECM-системи, що визначаються як программ комплекси управлтня корпоративним контентом. У рамках цих пiдходiв пропонуеться тструментальна модель прототипу тдсистеми тдт-римки прийняття ршень у складi програмного комплексу СЦ, зокрема, на етапах тдготовки i проведення наради. Шд тструментальною моделлю розумiеться сукупмсть програмних компоне-нтiв тдсистеми i ршень щодо гх стльного застосування. Модель веб-орiентованог програмног реалiзацiг тдсистеми включае програмну платформу Spring Framework, що загалом забезпечуе побудову програмног тфраструктури тдсистеми; засоби бiблiотеки Junit та програмног платфо-рми Mockito для модульного та ттеграцтного тестування програмного коду; засоби об &ектно-реляцтного вiдображення Hibernate для роботи з даними; протокол HTTP Request-Response як основу взаемодИ серверног частини iз miентською; стандарт/специфтацт Open API опису тте-рфейив взаемодИ мiж серверною та miентською частинами; засоби формування web-сторток для вiдображення у браузерi користувача. Сукупмсть програмно-технологiчнихршень, представ-лених у моделi, успшно апробовано в системi тдтримки прийняття ршень щодо формування i оперативног реконфiгурацiг виробничих пламв виконання договорiв тдприемства. Ключов1 слова: ситуацтний центр (СЦ), прототипування програмних комплекив СЦ, ECM-системи, тструментальна модель програмног реалiзацiг.
Аннотация. Одной из важных задач в решении проблемы создания сети Ситуационных центров (СЦ) органов государственной власти Украины является отработка типовых решений в различных сферах проблематики проектирования, внедрения и функционирования СЦ. Целью статьи является попытка частичного заполнения некоторых имеющихся пробелов в отношении методологического и инструментального обеспечения реализации программного комплекса СЦ. Отмечается несомненная целесообразность применения итерационного (эволюционного) подхода к процессу проектирования СЦ с учетом реальных отечественных условий и рисков. В качестве возможной основы прототипирования СЦ рассматриваются современные ECM -системы, которые определяются как программные комплексы управления корпоративным контентом. В рамках этих подходов предлагается инструментальная модель прототипа подсистемы поддержки принятия решений в составе программного комплекса СЦ, в частности, на этапах подготовки и проведения совещания. Под инструментальной моделью понимается совокупность программных компонентов подсистемы и решений по их совместному применению. Модель веб-ориентированной программной реализации подсистемы включает программную платформу Spring Framework, которая в целом обеспечивает построение программной инфраструктуры подсистемы; средства библиотеки Junit и программной платформы Mockito для модульного и интеграционного тестирования программного кода; средства объектно-реляционного отображения Hibernate для работы с данными; протокол HTTP Request-Response как основу взаимодействия серверной части с клиентской; стандарт/спецификации Open API описания интерфейсов взаимодействия между серверной и клиентской частями; средства формирования web-страниц для отображения в браузере пользователя. Совокупность программно-технологических решений,
© Грибков С.В., Литвинов В.А., Олшник Г.В., 2020 ISSN 1028-9763. Математичш машини i системи, 2020, № 1
представленных в модели, успешно апробированы в системе поддержки принятия решений по формированию и оперативной реконфигурации производственных планов выполнения договоров предприятия.
Abstract. One of the most important tasks in solving the problem of creating a network of situational center (SC) ofpublic authorities in Ukraine is to develop standard solutions in various areas of the problems of design, implementation and functioning of the SC. The purpose of the article is an attempt to partially fill some of the gaps in terms of methodological and instrumental support for the implementation of the SC software. It is undoubtedly expedient to apply an iterative (evolutionary) approach to the process of designing a SC taking into account real domestic conditions and risks. As a possible basis for prototyping the SC are considered modern ECM-systems, which are defined as software complexes of corporate content management. These approaches propose an instrumental model of the prototype of a decision support subsystem as part of the SC complex, in particular during the preparatory and meeting stages. The instrumental model is understood as a set of software components of the subsystem and decisions on their joint application. The web-based software implementation model of the subsystem includes: Spring Framework software platform, which in general provides the construction of software infrastructure of the subsystem; means of Junit library and Mockito software platform for modular and integration testing of the code of the developed system; Hibernate object-relational mapping tools for working with data; HTTP Request-Response protocol as the basis for interaction between the server and the client side; standard / Open API specifications describing the interfaces between the server and client parts; means of forming web-pages for displaying them in the user&s browser. The set of software and hardware solutions presented in the model has been successfully tested in the decision support system for the formation and operational reconfiguration ofproduction plans for the implementation of contracts of the enterprise. Keywords: situational center (SC), prototyping of SC software systems, ECM-system, software instrumental model.
DOI: 10.34121/1028-9763-2020-1-73-81
В останш роки Ситуацшш центри (СЦ) набувають все бшьш широкого розповсюдження як штелектуальний шструмент тдтримки прийняття ефективних ршень для складних слабодетермшованих анал^ичних задач. Особливо велику роль вони ввдграють як зааб штелектуального забезпечення державного управлшня життедiяльнiстю суспшьства взага-лi i нащональною безпекою зокрема [1-3]. Виршення проблем координацп дiяльностi та взаемодп оргашв державно! влади Укра!ни на загальнодержавному та мiжнародному рiв-нях мае забезпечити створення мереж СЦ [4]. Одним iз найбшьш важливих завдань у зв&язку з цим стае тдготовка типових ршень у рiзних сферах проблематики створення, впровадження i функщонування СЦ.
Наявш втизняш i доступш шоземш публшаци за проблематикою СЦ присвячеш переважно загальним концептуальним питанням: структурним, функщональним, техноло-пчним аспектам побудови та використання СЦ, принциповим ршенням щодо оргашзацп шформацшного забезпечення СЦ, створення единого шформацшного простору мереж СЦ та ш. Питання належно! програмно! реалiзащi тдсистем та окремих функцш СЦ залиша-ються, поки що, якось «на узбiччi».
Метою даног статтг е спроба як внесення посильного вкладу в часткове заповнен-ня вщзначено! прогалини, зокрема, у вщношенш методолопчного та шструментального забезпечення реалiзацii програмного комплексу СЦ, так i привернення до ще! проблематики додатково! уваги фахiвцiв-проектантiв i вщповщних стейкхолдерiв.
Сyчаснi методологи i технологи створення складних програмних систем (RUP, MSF, XP тощо) засноваш на iтерацiйномy (еволюцiйномy) пiдходi до по6удови моделi процесy про-ектyвання. Стосовно до умов i реальних вггчизняних можливостей особливо&1 уваги заслу-говуе спiральна рiзновиднiсть еволюцiйноï моделi, орieнтована на урахування вiдповiдних десяти ризиюв, сформульованих Б. Боемом (дефiцит спещалю^в та розрив мiж 1хньою квалiфiкацieю й вимогами проекту, нереалiстичнi строки та бюджет тощо) i заснована на прототипуванш фрагмешив (пiдсистем) або версш програмного комплексу. В контекст проблеми прототипування та розробки типових ршень по створенню програмних компле-ксiв СЦ вiдзначимо, що на тепершнш час y сферi шформацшних технологiй склалася кон-цепцiя ECM-систем (Enterprise Content Management), що визначаються i позицiонyються як програмний комплекс управлшня корпоративним контентом, призначений, з одного боку, для створення единого шформацшного простору рiзноманiтних докумешив тдприемства, а з шшого - для управлшня процесами ix обробки та надання користувачам. У теперiшнiй час серед ГТ-спещалют1в та експертiв з управлшня корпоративними системами поки що так i не склалося единое& думки щодо термшологи i конкретних визначень функцш ЕСM-систем. Бшьш того, вважаеться, що ЕСM - це деякий «коктейль, рецептура якого може вiдрiзнятися вщ бара до бару» [5] . Проте вс визначення, в тому чист i визначення вiдомоï досл^ни^^ та консалтинговоï фiрми Gartner, що спецiалiзyeться на ринку ГТ, в основш функци включають yправлiння документами, мyльтимедiаконтентом (графiчними, аудю-та вiдеофайлами), знаннями (knowledge management), потоками робгг (workflow management), потоками докумешив (docflow management), спшьною роботою користyвачiв iз документами (collaboration management).
Окремим обмеженим випадком ЕСM-систем е системи електронного об^у докуме-нтiв (СЕД), позбавлених цiлоï низки важливих функцш, зокрема, workflow management, knowledge management, collaboration та ш. Вщзначимо, що видшення даноï категори систем (як i поняття «документообшу») прийнято y пострадянському простор^ де поняття ECM-систем найчастiше збшаеться з поняттям СЕД [б, 7].
Розглядаючи програмний комплекс Ситyацiйного центру як розширену ЕСM-систему специфiчного «пщприемства» (а для цього, на наш погляд, е достатньо тдстав), вщзначимо, по-перше, що саме вщзначеш вище функци е одними з найбшьш важливих для цшей створення СЦ, а по-друге, що арх^ектурш пiдxоди i програмнi рiшення, прийня^ в наявних ЕСM-системаx, можуть, як мшмум, бути корисними для створення програмного комплексу повнофункцюнальних СЦ.
У тепершнш час ринок класичних ЕСM-систем для «звичайних» корпорацiй нара-ховуе ряд конкретних систем, що пропонуються рiзними виробниками, в тому чист i ро-сiйськими. Десять найбшьш популярних систем описанi i охарактеризовав в [8]. При по-бyдовi наведених ЕСM-систем використовуються рiзнi арх^ектурш рiшення, порiвняно простим прикладом яких, близьким до структурних рiшень СЦ, може бути загальна архь тектура ЕСM фiрми «Галактика» [9] (рис. 1). Основою для розширеноï конкретизаци складу фyнкцiональниx пiдсистем програмного комплексу ЕСM СЦ порiвняно з наведеним прикладом може слугувати орieнтовна типова структура процесiв СЦ, рекомендована в [10].
У контекстi задачi прототипування i вiдпрацювання типових проектних рiшень СЦ як специфiчноï ЕСM-системи можна вiдзначити два можливих пщходи:
- адаптацiя i використання готових free и open-sourse ЕСM-платформ [9, 11];
- розробка на базi щеологи i апробованих арxiтектyрниx ршень ЕСM спецiалiзова-них програмних систем i моделюючих комплекав, орieнтованиx безпосередньо на задачi i особливостi СЦ.
в и Й р о п портал
со р^
« о й
<и и о
^ (и м
Галактика ЕСМ.Согр
Пщсистема користувацького iнтерфейсу Галактика ECM Toolkit
Пщсистема управлшня 61знес-процесами
Галактика BPM4ЕСМ Системи класу BPM
Пвдсистема управлшня даними
Галактика ЕСМ
Пщсистема штеграци шформацшного наповнення Система постачання
повщомлень Системи класу ES8
Щдсистема пщтримки прийняття ршень В1 компоненти
Гео-тдсистема Галактика GIS4CEM Ктент-серверне ршення для роботи с ГЕО даними
Галактика Scan2ECM
Промислов1 бази даних
Файлова система
SOAF/REST
Файловий обмiн
Облiковi системи
Оператор ЕДО
Рисунок 1 - Функцюнальна структура ЕСМ «Галактика ЕСМ.Согр»
Перший пiдхiд потребуе окремого розгляду i спецiальних, досить масштабних i ре-сурсомiстких дослщжень. У рамках другого пiдходу, як деякий крок в step_by_step-процесi створення типових програмних комплексiв, ми розглянемо можливу шструментальну модель прототипу веб-орiентованоi програмно&1 реалiзацii пiдсистеми пщтримки прийняття рiшень у складi сервера СЦ, зокрема, на етапах пщготовки i проведення наради [10]. Вщ-значена пiдсистема е основою виконання функцп колективного обговорення проблеми (соПаЬогайоп), а пiд iнструментальною моделлю тут розумiеться сукупнiсть програмних компонентiв тдсистеми i рiшень щодо 1&х спшьного застосування. Використання саме веб-штерфейсу обгрунтовуеться рядом факторiв, серед яких не останне мюце посiдае необхщ-нiсть роботи у процесi наради з вщдаленими учасниками-експертами.
До основних компоненпв системи, що розглядаеться, належать шформацшш ресурси СЦ, серверна частина, web-iнтерфейс користувача (рис. 2).
Ршення щодо побудови програмно&1& серверно&1 частини базуються на класичнiй ба-гатошаровш архiтектурi з розподiленням на таю складов^
- шар контролерiв, за допомогою яких забезпечуеться взаемодiя iз клiентською частиною;
- адаптери, на рiвнi яких здiйснюеться перетворення даних iз запитiв клiентiв у основы бiзнес-об&екти, над якими здшснюеться подальша обробка;
- класи, що здшснюють перевiрки вхiдних даних на вщповщшсть встановленим правилам;
- бiзнес-сервiси, якi безпосередньо вiдповiдають за виконання бiзнес-логiки;
- допомiжнi шструментальш класи, яким 6i3Hec-cepBiOT делегують виконання окре-мих операцш;
- репозитори, призначенi для безпосередньо&1 роботи з даними.
База даних
База знань
Серверна частина
Репозитари
Iнструментальнi класи
Бiзнес-сервiси
Валщатори
Адаптери
Контролери
Функцiональнi модулi
Модуль безпеки
REST - U —W VEB-штерфейс користувача
Internet/Intranet
КОРИСТУВАЧ1
Рисунок 2 - Структура системи
Функщональш можливосп серверно& частини вiдповiдають потребам користувачiв i у загальному виглядi розподшеш на модулi, призначенi для виршення конкретних задач, що реалiзують функщонал системи, зокрема, на етапах тдготовки i проведення наради. Кожен модуль при виконанш обробки деякого запиту звертаеться для отримання даних до шформацшних ресурсiв системи. Пiсля проведення обробки даних та необхщних тдраху-нкiв результат вiдображаеться клiентською частиною у заданому виглядi. Кiлькiсть моду-лiв не регламентуеться, чим забезпечуеться, у випадку необхщносп, модернiзацiя юную-чих та включення нових модулiв для вирiшення задач прийняття ршень.
Розробка програмно&& логiки роботи модулiв на сервернiй частинi здiйснюеться мо-вою програмування Java, вибiр яко& зумовлений вiдомими перевагами [12], з використан-ням Spring Framework та Hibernate. Незважаючи на те, що мова програмування Java надае значну кшьюсть вбудованих функщональних можливостей для розробки шформацшних систем, засоби для оргашзаци складових програмних частин складно&& системи у едине цiле не надаються. Вирiшення тако& проблеми покладаеться безпосередньо на розробниюв та архггекг^в. Для розв&язання дано&& задачi обрана програмна платформа Spring Framework, що надае формашзоваш засоби об&еднання розрiзнених компонентiв у едину програмну систему на основi принципу введення залежностей (Dependency Injection) [13]. У вщповщ-носп iз вказаним принципом задача побудови залежностей об&екта виршуеться за допомогою зовшшнього MexaHÍ3My. Ключове призначення програмно&1 платформи Spring Framework полягае у 3a6e3ne4eHHÍ побудови програмно&1 шфраструктури системи.
Spring Framework мае модульну структуру, яка дозволяе використовувати лише не-обхщш для реашзаци функцш системи елементи [14].
Модyлi об&еднаш у групи за фyнкцiональним призначенням (рис. 3), а саме:
- ядро програмно^! платформи (Core Container);
- модyлi доступу до даних (Data Access/Integration);
- модyлi для розробки Web-орiентованих систем (Web);
- модyлi для роботи з аспектно-орiентованим програмуванням (AOP - Aspect Oriented Programming);
- шструментальш модyлi (Instrumentation);
- тестовi модyлi (Test).
CoreContainer (ядро програмно&1 платфор-ми)
Web modules (модyлi для розробки Web-орiентованих систем)
WebSocket
Data Access/Integration modules (модул1 доступу до даних)
JDBC |[~~OrM~|[ OXM ~|[ JMS )[ Transactions&
ЛОР modules(модyлi для роботи з aспeктно-орieнтовaним програмуванням)
Instrumentation modules (шструментальш модул^
Test modules (модyлi для тестування)
Рисунок 3 - Модул1 програмноï платформи Spring Framework, розподшеш на групи за функцюнальним призначенням
Фундаментальну частину програмно&1& платформи Spring Framework складають мо-дулi Beans та Core, якi забезпечують можливостi введення залежностей мiж компонентами серверно&1& частини системи СППР. Саме це дозволяе вщокремити конфiгурацiю системи та специфшащю залежностей об&ектiв. Модуль Context розширяе Beans, надае вбудовану тд-тримку тако&1& функцiональностi:
- локалiзацiя та iнтероперабельнiсть i3 використанням пакетв ресурсiв;
- використання та поширення подiй мiж компонентами для керування поведiнкою;
- створення програмних середовищ (контекстiв) для управлiння часом юнування та взаемодiею компонентiв (наприклад, контейнер сервлетв).
Модуль JDBC надае власний рiвень абстракци для безпосередньо&1& роботи з шфор-мацiйними ресурсами, що забезпечуе зменшення обсягiв роботи для розробниюв, а також виключае необхiднiсть обробки специфiчних помилок вщ конкретних систем управлiння базами даних. Модуль ORM представляе собою основу для роботи з технолопями для об&ектно-реляцшного вщображення, такими як Hibernate. Модуль для обмiну повщомлен-нями (JMS) надае функци для створення та отримання повщомлень, чим забезпечуеться взаемодiя зi стороннiми iнформацiйними системами. Модуль Transactions тдтримуе про-грамне та декларативне керування транзакщями, що надае можливосп для гнучкого керування цшсшстю даних, використовуваних системою, та едшсть операцiй, якi виконують-ся. Spring забезпечуе роботу з локальними та глобальними транзакщями без прив&язки до технологий реалiзащï. Надаеться досить широка тдтримка реалiзащï декларативних тран-закцiй як за допомогою ХМЬ-конфшураци, так i за допомогою анотацiй. Крiм цього, е можливють управляти транзакщями програмно, що зумовлюе гнучюсть при налаштуванш в залежност вщ конкретних вимог до функцюнальносп системи.
Модул1 для розробки Web-орiентованих систем надають основш можливосп розро-бки контролерiв Web-сервiсiв для Web-штеграци системи, що е ключовим для взаемодп серверно&1 частини з користувальницькою.
Модуль AOP вiдповiдае за роботу з аспектно-орiентованим програмуванням та за-безпечуе можливiсть створення методiв-перехоплювачiв. Таю методи е досить корисними за необхщносп виокремлення нас^зно& для рiзних об&ектiв функцiональностi. Також, можливостi аспектно-орiентованого програмування використовуються для додаткового ведення облшу шформацп про усi операцп, що здiйснюються пiд час роботи системи, з описом уах виклиюв та значеннями переданих аргументiв. Крiм цього, надаеться можли-вiсть штеграци з бiблiотекою AspectJ, яка надае розширеш способи перехоплення викликiв та впровадження деяко&1 програмно&1 логiки на рiзних етапах взаемодп з об&ектами.
Модульне та штеграцшне тестування програмного коду розроблювано&1 системи здiйснюеться з використанням:
- модулiв для тестування компоненпв пiд управлiнням Spring Framework у поед-наннi з бiблiотекою для модульного тестування Junit;
- програмно&1 платформи Mockito, яка дозволяе створювати об&екти-заглушки для iзольованоi перевiрки найменших фрагментiв коду у вщповщносп iз принципами пiдходу модульного тестування.
Вибiр програмно!& платформи для побудови арх^ектури шформацшно&& системи обумовлений можливютю повно& незалежностi бiзнес-логiки вiд елеменпв програмно&& платформи та iзольованiстю залежностей на компоненти вiд решти програмного коду. Дана перевага надаеться Spring Framework, що також вплинуло на и вибiр як програмно&& платформи для побудови програмно&& арх^ектури.
Особлива увага мае придшятися робот iз джерелами даних, оскшьки взаемодiя мiж об&ектами об&ектно-орiентованоi мови програмування та реляцшною базою даних громiзд-ка та трудомiстка, що зумовлено, як вщомо, невiдповiднiстю парадигм збершання даних, представлених класами об&екпв i таблицями баз даних. Для зв&язування баз даних з конце-пщями об&ектно-орiентованих мов програмування доцшьним е використання технологи ORM (Object-Relational Mapping - об&ектно-реляцшне вiдображення). Концепщя ORM у Java EE представлена специфкащею JPA (Java Persistence API).
Для роботи з даними використовуеться одна з реалiзацiй тдходу об&ектно-реляцiйного вiдображення, а саме Hibernate. Задачею Hibernate е перенесення даних iз ряд-кiв таблиць бази даних у об&екти Java i навпаки [15]. Крiм цього, Hibernate надае вбудоваш можливостi для запипв i пошуку, що дозволяе скоротити час розробки, який витрачаеться на ручну обробку даних в SQL i JDBC. Проте, на вщмшу вщ багатьох подiбних рiшень, Hibernate не приховуе потужност SQL i дозволяе за необхiдностi використовувати реля-цiйнi технологи напряму. Вибiр Hibernate також зумовлено вщсутшстю необхiдностi у складнш взаемодп з базою даних, використанням складних запитiв тощо, оскшьки оперу-вання даними вiдбуваеться на програмному рiвнi. У порiвняннi з аналогами (наприклад, MyBatis), Hibernate вщразу пропонуе готове рiшення, початковi вимоги до конфшурування якого мiнiмальнi.
Загальну схему взаемодп рiвня доступу до даних шформацшно&& системи з реляцшною базою даних iз використанням Hibernate зображено на рис. 4.
Взаемодiя мiж кодом шформацшно&& системи та функцюнальними можливостями Hibernate вщбуваеться через стандартний iнтерфейс доступу JPA, а також через розшире-ний штерфейс Hibernate, який надае додатковi можливостi.
Рисунок 4 - Схема взаемоди рГвня доступу до даних i3 використанням Hibernate
ВзаемодГя серверно&1& частини i3 клiентською здiйснюеться мережею iRTepReT/Intranet за протоколом HTTP Request-Response з використанням щеологп архГтектурного стилю для розподшених систем REST (Representational State Transfer), що дозволяе вщокремити лопку системи вщ iнтepфeйсу користувача, а структуру системи зробити бшьш простою та масштабованою [16].
Для фоpмалiзованого опису штерфейав взаемодп мiж серверною та користуваль-ницькою частиною використовуеться специфшащя Open API, iз застосуванням яко&& опи-суються усi ресурси, що надаються серверною частиною, та доступш операцп над ними. Фактично, дана специфшащя визначае стандарт опису REST штерфейав, який дозволяе взаемодiяти з серверною частиною без доступу до вихщного коду, додатково&& техшчно1 документацп або прямо&& взаемодп через мережу [17].
Розробка програмного коду здшснюеться з використанням пiдходу неперервно&& ш-теграци CI (Continuous Integration) та програмного продукту Jenkins [18]. При ix викорис-таннi кожна змша програмного коду автоматично фiксуеться та тестуеться. При цьому автоматично виконуються таю ди, як компшящя, завантаження та оновлення схем баз даних, збГрка на сepвepi. Використання CI знижуе ризик появи невиявлених вiдpазу проблем, спрощуе вдосконалення програмного коду, виконуе автоматизащю тpивiальниx дш, що дозволяе зосередитися на розробщ програмно! логГки пГдтримки функцiональниx можли-востей системи.
Запропоноваш загальнi пщходи до створення типових piшeнь щодо програмно! реалГзацп пiдсистeм СЦ на основГ щеологп i готових програмних рГшень ECM-систем носять, зви-чайно, дискусшний характер, проте можуть, як сподiваються автори, привернути увагу фаxiвцiв i кepiвникiв, вГд яких залежить фшансування вГдповГдних науково-дослiдниx та дослщно-конструкторських ро6Гт, саме пГд цим кутом зору.
Наведена модель штероперабельно! сукупносп програмних платформ забезпечуе виконання вах основних eтапiв по створенню пщсистеми пГдтримки прийняття piшeнь -вщ побудови програмно1 Гнфраструктури пГдсистеми до модульного та штеграцшного тес-тування програмного коду. Слщ зауважити, що одшею з важливих властивостей запропо-новано!& моделГ е легке застосування систем захисту вщ стандартного легування до впрова-дження електронно-цифрових пщпиав. СукупнГсть програмно-технологГчних рГшень, представлених у моделГ, успГшно апробовано в системГ пГдтримки прийняття рГшень щодо формування i оперативно! реконфГгурацп виробничих плашв виконання договорГв пщпри-емства [19].
Загалом модель мае загальний, «скелетний» характер i потребуе уточнення i розви-тку для конкретних застосувань. Зокрема, наведеш програмнi рiшення базуються переваж-но на концепцп «тонкого ^ента», що передбачае створення вiдповiдних модушв для ви-рiшення кожно&1& пщзадач^ з яких складаються окремi функцп системи. Для деяких сукуп-ностей задач СЦ такий тдхщ може виявитися нерацiональним.
СПИСОК ДЖЕРЕЛ
Стаття надтшла до редакцп 12.12.2019
