Артефакти в BPMN.
Артефакти використовуються для введення додаткової інформації по процесу. Існує три стандартних артефакту, але розробник або інструмент моделювання можуть додати стільки артефактів, скільки потрібно. BPMN може зробити додаткову спробу привести велику сукупність артефактів до єдиного стандарту для загального використання, або для вертикальних ринків. Дана сукупність артефактів включає в себе: а) Об'єкт даних, б) Група, в) Анотація.
а) Об'єкт даних
Об'єкти даних розглядаються як артефакти, так як вони не впливають безпосередньо на послідовний потік або потік повідомлень процесу, але вони забезпечують інформацію про те, які дії вимагають виконання і / або що вони виробляють.
б) Група (прямокутник навколо групи об'єктів з метою документування)
Угруповання дій, що не роблять впливу на послідовний потік. Угруповання може використовуватися в цілях документування або аналізу. Групи можуть також використовуватися для розпізнавання дій операції, розподіленої по ширині області.
в) Текстова анотація (пов'язана з асоціацією)
Текстова анотація - спосіб надання додаткової інформації для вивчає схему BPMN.
Діаграми кооперації в UML
Діаграми кооперації відображають потік подій через конкретний сценарій варіанта використання, впорядковані за часом, а кооперативні діаграми більше уваги звертають пильну на зв'язках між об'єктами.
Діаграма кооперації рівня прикладів представляється сукупністю об'єктів (екземпляри класів) і зв'язків (екземпляри асоціацій)
На діаграмі кооперації представлена вся та інформація, яка є і на діаграмі послідовності, але кооперативна діаграма по-іншому описує потік подій. З неї легше зрозуміти зв'язку між об'єктами, однак, важче усвідомити послідовність подій.
На кооперативної діаграмі так само, як і на діаграмі послідовності, стрілки позначають повідомлення, обмін якими здійснюється в рамках даного варіанту використання. Їх тимчасова послідовність вказується шляхом нумерації повідомлень.
В окремих випадках виникає необхідність явно вказати той факт, що кооперація є реалізацією деякої операції або класифікатора.
Інформаційні технології дистанційного банківського обслуговування.
Дистанційним банківським обслуговуванням (ДБО) прийнято називати надання банківських послуг (надання банківських продуктів) на відстані, без відвідування клієнтами офісу банку, без безпосереднього контакту з працівниками банку - з будинку, офісу, автомобіля і т. д.
Такий вид обслуговування дозволяє клієнту контролювати власні рахунки, купувати і продавати безготівкову валюту, оплачувати комунальні послуги, доступ в Інтернет, рахунки операторів стільникового зв'язку, проводити безготівкові банківські і міжбанківські платежі, переказувати кошти за рахунками та ін
За технологіями надання послуг ДБО класифікують наступним чином: системи "Банк-Клієнт", інтернет-банкінг, відео-банкінг, телефонний банкінг, термінальний банкінг, мобільний банкінг (WAP-банкінг, SMS-банкінг, SlM-аинлет, мідлет).
Система "Банк-Клієнт" є програмно-технічний комплекс, що дозволяє організувати взаємодію в захищеному off-line-режимі клієнта з банком
Інтернет-банкинг , по суті, з'явився подальшим розвитком системи "Банк-Клієнт" і має перед нею ряд переваг. Наприклад, використання відкритої мережі дозволяє необмежено розширити коло потенційних клієнтів, але одночасно знижує рівень безпеки системи.
Видеобанкинг - це система інтерактивного спілкування клієнта з персоналом банку, свого роду відеоконференція, для організації якої використовується пристрій, зване кіоском
Телефонний банкінг - надання дистанційних фінансових послуг за допомогою звичайного телефонного з'єднання.
Система IVR (interactive voice response) - інтерактивна інформаційна система, яка дозволяє надавати інформацію у режимі реального часу, так і проводити обробку команд (розпоряджень) клієнтів.
Голосовий банкінг - застаріла система взаємодії банку та клієнта, передбачає спілкування клієнта з фахівцем call-центру.
Мобільний банкінг передбачає використання мобільного телефону в якості терміналу для доступу до ДБО.
WAP-банкінг - віддалене управління рахунками за допомогою мобільного телефону, оснащеного спеціальним програмним забезпеченням на базі протоколу бездротової передачі даних. Мідлет - платіжне JAVA-додаток, що працює в пам'яті мобільного пристрою і дозволяє проводити фінансові транзакції в захищеному режимі.
Інформаційні технології дистанційного банківського обслуговування.
Дистанційне банківське обслуговування – це нематеріальна інформаційна форма ведення комерційно- банківського бізнесу в міжнародному онлайн просторі. Тенденції їх формування мають могутній вплив на міжнародний електронний бізнес та міжнародну валютно-фінансову сферу, банківську систему, що систематично підлягають фінансовим кризам, світовим валютним трансформаціям. Тому, нестабільність сучасної світової банківської системи, системні трансформаційні фінансові процеси потребують новихпідходів до вирішення проблем міжнародного електронного бізнесу потребує нових знань, новітніх інструментів, що актуалізує необхідність подальшого наукового дослідження та впровадження новихінструментів і технологій.
Технології дистанційного банківського обслуговування класифікують за наступними типами інформаційних систем, які використовуються для здійснення банківських операцій (каналів доступу до банківських послуг). 1. PC"банкінг (банкінг з використанням персональ" ного комп'ютера — PC"banking) — це тех" нологія дистанційного банківського об" слуговування, що передбачає установку на комп'ютер клієнта відповідного по" грамного забезпечення
2. Інтернет"банкінг (Internet"banking) — це технологія дистанційного банківського обслуговування, за якої доступ до рахунків і операцій по рахунках надаєть" ся в будь"який час і з будь"якого комп'ю" тера, що має доступ в Інтернет.
3. Мобільний банкінг (mobile"banking) є найновішим дистанційним каналом до" ставки банківських послуг; це технологія дистанційного банківського обслугову" вання, яка передбачає установку на мо" більний телефон клієнта необхідного програмного забезпечення
4. Телефонний банкінг (phone"ban" king, також використовується термін те" лебанкінг) — це технологія дистанційно" го банківського обслуговування, яка надає можливість отримувати по телефону інфор" мацію про стан рахунків, пластикових карт і платежів у банку.
5. Обслуговування з використанням банкоматів (ATM"banking) та засобів банківського самообслу" говування.
Попри інтенсивний розвиток дистанцій" ного банківництва в світі, даний вид обслуговування клієнтів в Україні знаходиться на почаковому етапі роз" витку, а більшість банків пропонує лише окремі послу" ги в режимі реального часу. При цьому популяризація електронних банківських послуг, удосконалення існу" ючих та запровадження новітніх систем дистанційного банкінгу у майбутньому надасть додаткові конкурентні переваги комерційним банкам та призведе до розширен" ня їх клієнтської бази, зростання ефективності, оздо" ровлення та підвищення довіри до банківської систем в цілому.
Для організації дистанційного обслуговування в банках виділяється окремий WEB-сервер, до якого мають доступ територіально віддалені філії, безбалансові відділення та виносні пункти роздрібного обслуговування клієнтів, які розташовані в торгівельних закладах, а також клієнти, які використовують послуги Інтернет-банкінгу. Виділення окремого WEB-сервера обумовлено необхідністю захисту основного сервера бази даних АБС від несанкціонованого доступу. Дворівневий „клієнт-сервер” при складній логіці прикладних програм і збільшенні кількості функціональних задач, ставить досить високі вимоги до комп’ютерів користувачів. Для реалізації складної прикладної логіки для АРМ користувачів виділяти досить потужні машини, що призводить до виникнення явища, яке дістало назву “товстого” клієнта. Усунення цього недоліку досягається трьохрівневою архітектурою, коли виділяється проміжний між сервером БД та користувачем (клієнтом) сервер застосувань (додатків), на якому реалізується вся бізнес-логіка. За такої архітектури, клієнт спілкується лише з сервером застосувань, а сервер застосувань взаємодіє з СКБД. Тобто клієнтські програми взагалі не можуть звертатися до СКБД, оминаючи сервер застосувань. Така архітектура забезпечує високу ефективність і надійність системи в цілому, дає можливість нарощувати потужність окремих компонентів, дозволяє успішно вирішувати задачі адміністрування та забезпечує високий рівень безпеки, а також надає можливості інтеграції з зовнішніми програмними продуктами і реалізацію веб-решень. Клієнтські додатки можуть бути реалізовані не лише вбудованими засобами розробки, але і за допомогою будь-яких програмних середовищ, що підтримують COM/DCOM: VisualBasic, Java, Visual C++, Delphi та інші.
Характеристика CASE-технологій. Класифікація CASE-засобів.
Зазвичай до CASE-засобів відносять будь-яке програмне засіб, що автоматизує ту чи іншу сукупність процесів життєвого циклу ПЗ і має такими основними характерними особливостями:
потужні графічні засоби для опису і документування ІС, що забезпечують зручний інтерфейс з розробником і розвиваючі його творчі можливості;
інтеграція окремих компонент CASE-засобів, що забезпечує керованість процесом розробки ІС;
використання спеціальним чином організованого сховища проектних метаданих (сховища).
Інтегроване CASE-засіб (або комплекс засобів, що підтримують повний ЖЦ ПЗ) містить наступні компоненти;
репозиторій, що є основою CASE-засобу. Він повинен забезпечувати зберігання версій проекту і його окремих компонентів, синхронізацію надходження інформації від різних розробників при груповій розробці, контроль метаданих на повноту і несуперечність;
графічні засоби аналізу і проектування, що забезпечують створення і редагування ієрархічно пов’язаних діаграм (DFD, ERD та ін), що утворюють моделі ІС;
засоби розробки додатків, включаючи мови 4GL і генератори кодів;
засоби конфігураційного управління;
засоби документування;
засоби тестування;
засоби управління проектом;
кошти реінжинірингу.
Всі сучасні CASE-засоби можуть бути класифіковані в основному за типами і категоріями. Класифікація за типами відображає функціональну орієнтацію CASE-засобів на ті чи інші процеси ЖЦ. Класифікація по категоріях визначає ступінь інтегрованості по виконуваних функцій і включає окремі локальні засоби, вирішальні невеликі автономні задачі (tools), набір частково інтегрованих засобів, охоплюють більшість етапів життєвого циклу ІС (toolkit) і повністю інтегровані засоби, що підтримують весь ЖЦ ІС і пов’язані спільним репозиторієм. Крім цього, CASE-засоби можна класифікувати за наступними ознаками:
застосовуваним методологіям і моделям систем і БД;
ступеня інтегрованості із СУБД;
доступним платформам.
Класифікація за типами в основному збігається з компонентним складом CASE-засобів і включає наступні основні типи:
засоби аналізу (Upper CASE), призначені для побудови та аналізу моделей предметної області (Design / IDEF (Meta Software), BPwin (Logic Works));
засоби аналізу і проектування (Middle CASE), що підтримують найбільш поширені методології проектування і що використовується для створення проектних специфікацій (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Виходом таких засобів є специфікації компонентів і інтерфейсів системи, архітектури системи, алгоритмів і структур даних;
засоби проектування баз даних, що забезпечують моделювання даних і генерацію схем баз даних (як правило, на мові SQL) для найбільш поширених СУБД. До них відносяться ERwin (Logic Works), S-Designor (SDP) і DataBase Designer (ORACLE). Засоби проектування баз даних є також у складі CASE-засобів Vantage Team Builder, Designer/2000, Silverrun і PRO-IV;
засоби розробки додатків. До них відносяться засоби 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) Тощо) і генератори кодів, що входять до складу Vantage Team Builder, PRO-IV і частково – в Silverrun;
кошти реінжинірингу, що забезпечують аналіз програмних кодів і схем баз даних і формування на їх основі різних моделей і проектних специфікацій. Засоби аналізу схем БД і формування ERD входять до складу Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin і S-Designor. У галузі аналізу програмних кодів найбільше поширення одержують об’єктно-орієнтовані CASE-засоби, що забезпечують реінжиніринг програм на мові С + + (Rational Rose (Rational Software), Object Team (Cayenne)).
Допоміжні типи включають:
засоби планування та управління проектом (SE Companion, Microsoft Project та ін);
засоби конфігураційного управління (PVCS (Intersolv));
засоби тестування (Quality Works (Segue Software));
засоби документування (SoDA (Rational Software)).
Основні типи діаграм BPMN .
Діаграми процесів - фокусуються на потоці операцій в одному процесі.
Діаграми взаємодій - можуть додатково відображати повідомлення, що передаються між учасниками. Учасники можуть відображатися у вигляді чорних квадратів або з процесами всередині.
Діаграми діалогів - надають огляд комунікацій між учасниками. Діаграми діалогів можна створювати і обробляти в настільному клієнта PowerDesigner, в PowerDesigner Web вони доступні тільки для читання.
Хореографічні діаграми - фокусуються на докладних даних діалогів між двома або кількома учасниками; часто прив'язуються до конкретних вузлів діалогів.
Діаграми послідовності в UML
Діаграми послідовності є одним з двох видів діаграм взаємодії (interaction). Вони представляють собою моделі, що описують поведінку взаємодіючих груп об’єктів в рамках одного варіанту використання.
На діаграмах послідовності використовуються наступні елементи:
Об’єкти - зображаються прямокутниками по горизонталі у верхній частині вікна ті об’єкти, які беруть участь у реалізації варіанта використання, що розглядається.
Лінія життя об’єкта – зображається вертикальною пунктирною лінією, що відходить від об’єкта вниз, представляє собою його житєвий цикл в процесі взаємодії.
Прямокутник активності – видовжений до низу прямокутник малюється на лінії життя об’єкта, щоб показати період часу, на протязі якого об’єкт є активним (якщо він не вказується – діаграми складніше розуміти).
Повідомлення - представляється стрілкою між лініями життя двох об’єктів та помічається іменем. За часом більш ранніми є ті повідомлення, що знаходяться вище
Принципи функціонування СЕП-2.
«Друга» модель роботи банку в СЕП так само, як і «перша», належить до регіональних моделей з єдиним кореспондентським рахунком. Але тут на відміну від «першої» моделі філії банку мають лише номер МФО.
Принципова різниця між «першою» і «другою» моделями полягає в тому, що під час роботи за «другою» моделлю всі філії банку взаємодіють із СЕП через АРМ-3 ГБ. Інших АРМ-3 у системі банку немає, тоді як згідно з «першою» моделлю АРМ-3 є в кожній філії банку, і вона сама виходить у СЕП.
Отже, платежі між філіями банку не відображаються в СЕП, а взаємодія ГБ і філій ГБ відбувається в кілька етапів.
1. Філії доставляють свої платіжні документи до відповідного ГБ. (Способи доставляння можуть бути різними: кур’єром — паперові ПД, а також паперові ПД з копією на машинних носіях (дискети, НМЛ); по каналах зв’язку — у формі електронних документів).
2. ГБ групує документи, які надійшли до нього від філій, поділяючи їх на групи «міжфілійні платежі» та «інші».
3. Документи «інші», тобто ті, одержувачами яких є інші банки, у ГБ оформляються як файл початкових платежів (тип А) і відправляються до СЕП через АРМ-3 головного банку.
Аналогічно всі платежі інших банків до ГБ та його філій надходять від СЕП до АРМ-3 ГБ у вигляді файлів зворотних платежів (файл типу В). Розподіл та групування отриманих документів по філіях і їх доставка в філії-одержувачі реалізується засобами ГБ.
Отже, за такою технологією СЕП приймає пакети початкових платежів лише від ГБ і надсилає пакети зворотних платежів лише на ГБ, філії не мають безпосереднього зв’язку із СЕП, оскільки не оснащені АРМ-3, хоча можуть мати абонентський пункт ЕП НБУ. Усі звітні повідомлення СЕП також формуються і подаються лише для ГБ і включають дані про всі платежі, проведені останнім і його філіями через СЕП.
Усі файли СЕП, якими обмінюється ГБ і РРП, містять «електронну адресу» лише ГБ. При цьому у файлах типу А містяться первинні платежі як ГБ, так і його філій. Порядок розміщення платежів може бути вільним. У файлах типу А як МФО банку-відправника можуть бути зазначені МФО ГБ та МФО його філій, але вони не можуть бути вказані як МФО банку-одержувача, оскільки це означатиме помилку типу «платіж сам на себе». Аналогічно у файлі В як МФО банку-одержувача можуть бути зазначені як ГБ, так і його філії.
У файлі виписок для головного банку (тип V) містяться всі початкові та зворотні платежі як головного банку, так і його філій. Порядок, в якому платежі вміщені у файлі виписок, такий самий, як у файлах A і B.
У разі об’єднання банків, під час реорганізації системи управління або за інших умов, можливе переведення банківської установи з роботи за «нульовою» чи «першою» моделлю на роботу за «другою» моделлю. При цьому банківська установа усувається як безпосередній учасник СЕП і працює в СЕП «опосередковано» через свій ГБ. З огляду на це слід забезпечити відсутність у СЕП платежів, які були адресовані безпосередньо їй як учаснику СЕП. Для цього протягом приблизно трьох днів виконується відповідна робота в АРМ-1, АРМ-2 і ОДБ ТУ НБУ.