Відмінності між діаграмами процесів та взаємодії в BPMN
Діаграми взаємодій - можуть додатково відображати повідомлення, що передаються між учасниками. Учасники можуть відображатися у вигляді чорних квадратів або з процесами всередині.
Діаграми процесів - фокусуються на потоці операцій в одному процесі
Діаграми кооперації UML
Вони представляють собою моделі, що описують обмін повідомленнями між об’єктами в рамках певного варіанту використання.
На діаграмах кооперацій зображаються:
екземпляри об’єктів – позначаються піктограмами-прямокутниками;
зв’язки між об’єктами – показуються лініями;
повідомлення – позначаються стрілками та описуються текстом.
Часова послідовність обміну повідомленнями вказується нумерацією повідомлень.
Діаграми кооперації в UML
такі діаграми показують, як об'єкти працюють разом для досягнення спільної мети, акцентуючись на їх ролях.
кооперація може бути представлена на двох рівнях:
• На рівні специфікації - показує ролі класифікаторів і ролі асоціацій в розглянутому взаємодії.
• На рівні прикладів - вказує екземпляри і зв'язку, що утворюють окремі ролі в кооперації.
Діаграма кооперації рівня специфікації показує ролі, які грають беруть участь у взаємодії елементи
Діаграма кооперації рівня прикладів представляється сукупністю об'єктів і зв'язків. При цьому зв'язки доповнюються стрілками.
Моделі функціонування СЕП-2.
Модель функціонування СЕП – це спосіб взаємодії та форма обслуговування кореспондентського рахунку. Кореспондентський рахунок використовується для проведення міжбанківських розрахунків. В деяких випадках, коли банк є системним, має філії, в НБУ може відкриватись консолідований рахунок на якому відображається стан наприклад декількох або усіх філій в регіоні. Кореспондентський та консолідований рахунки є статичними тому що облік на них ведеться загальними сумами підсумкових оборотів за деякий проміжок часу. Технічний кореспондентський рахунок – це динамічний рахунок на якому облік ведеться в реальному часі і відображення операцій здійснюється по кожному документу.
При відкритті операційного дня в НБУ з ОДБ передається до РРП інформація про залишок коштів на консолідованих коррахунках комерційних банків і проводиться звірка із станом технічних коррахунків, а при необхідності здійснюється корегування ТКР. На протязі операційного дня всі документи що поступають або відправляються відображаються на технічному коррахунку. По закінченні операційного дня стан ТКР в РРП передається в ОДБ НБУ для звірки та виконання проводок по консолідованому коррахунку. При чіткій роботі залишки на ТКР та консолідованому коррахунку на початок слідуючого операційного дня мають співпадати.
Враховуючи потреби комерційних банків в СЕП НБУ реалізовано декілька моделей обслуговування консолідованого коррахунку. Вибір моделі завжди залишається за банківською установою в залежності від її потреб, можливостей та структури.
Нульова модель. Всі установи банківської системи є рівноправними учасниками СЕП НБУ і мають свої власні АРМ-3. Всім як філіям так і регіональним управлінням, головному банку відкриваються самостійні коррахунки в НБУ, а в РРЦ відповідно технічні коррахунки. Міжбанківські операції кожна установа може виконувати в межах наявних коштів на своїх власних коррахунках, незалежно одна від одної. Розпоряджатися коштами своїх підлеглих установ ні головний ні регіональний банк не може. Модель призначена для роботи на рівні банківського регіону.
Перша модель. Всі установи банківської системи також є учасниками СЕП НБУ і мають свої власні АРМ-3. В РРП відкривається єдиний коррахунок для головного банку та його підлеглих установ облік на якому ведеться загальними сумами без виділення вкладу кожної філії окремо. Філіалам відкривається технічний коррахунок в РРП. Головний банк має можливість управляти розміром коштів на кореспондентському рахунку шляхом виділення лімітів для роботи кожній підлеглій установі. Виділені ліміти надаються файлом типу ^L і філія може виконувати платежі в межах: “величини ліміту” +” вели-чина технічного коррахунку за операційний день.” Механізм розподілу лімітів дозволяє встановлювати заборону на роботу філій до отримання файлу лімітів, заборону на роботу філії взагалі при виділенні нульового ліміту, перерозподіл коштів між філіями на розгляд головного банку. Модель призначена для роботи на рівні банківського регіону.
Друга модель. Розвиток першої і також поширюється на банківський регіон. За даною моделлю учасниками СЕП НБУ є регіональні банківські установи та головний банк з власними АРМ-3. Регіональним управлінням та головному банку в РРП відкриваються єдині регіональні коррахунки та технічні коррахунки. Підлеглі філії не мають своїх коррахунків, технічних коррахунків і не є учасниками СЕП НБУ. Філії утворюють внутрішню платіжну систему для роботи якою в балансі регіональної установи відкриваються субкоррахунки для кожної філії. Філіали є самостійними банківськими установами, мають свій МФО й знаходяться в списку учасників СЕП НБУ, але свого АРМ-3 не мають.
Третя модель. Учасником СЕП НБУ є лише головний банк, що має АРМ-3, єдиний коррахунок та технічний коррахунок в РРП і власну внутрішню платіжну систему. Модель поширюється на банківський регіон. Головний банк має всі засоби контролю над роботою філій і може виконувати початкові платежі від імені філіалів. Кошти зосереджені виключно на одному рахунку, що дає можливість ефективно управляти ними та проводити контроль. Модель потребує наявності власної ВПС із засобами захисту та зв’язку для забезпечення транспортного рівня. Перерахування коштів із філії своєї системи в іншу філію своєї системи, але другого регіону, проводиться засобами своєї ВПС. В межах своєї ВПС всім філіям та регіональним управлінням відкриваються субкоррахунки на яких відображається облік руху коштів.
Четверта модель. Дана модель є територіальним розширенням першої і призначена для роботи в межах віртуального банківського регіону. Учасниками СЕП НБУ є всі установи системи і мають АРМ-3. Філії територіально можуть розміщуватись в різних регіонах незалежно від територіально-адміністративного поділу держави. Єдиний коррахунок відкривається головному банку, а технічні коррахунки всім установам. Кореспондентські рахунки всіх філій об’єднуються в консолідований рахунок, що контролюється головним банком. Головний банк контролює та управляє ресурсами з допомогою механізму лімітів. В ЦРП спеціально виділений АРМ-2 виконує функції розрахункових центрів для банків, що працюють в межах віртуального банківського регіону. Модель призначена для централізованого управління на рівні обмеження лімітування і не може керувати кожною трансакцією, тому її доцільно застосовувати для невеликих банків до 30 філій.
П’ята модель. Поєднує елементи другої та четвертої моделей, орієнтована на трьохрівневу організаційну структуру банку, працює в межах віртуального банківського регіону. Учасниками СЕП НБУ є головний та регіональні банки. Головному банку в РРП відкривається коррахунок і технічний рахунок, а регіональним управлінням лише ТКР. Головний банк та регіональні філії працюють за четвертою моделлю, а регіональні управління та підлеглі філії за другою, тобто створюють ВПС. Головний банк надає на початку операційного дня регіональним управлінням ліміти, а ТКР регіональних управлінь на початку дня обнуляються. ВПС зв’язує регіональні управління зі своїми філіями, яким відкриваються субкоррахунки. Регіональні управління можуть виконувати початкові платежі від імені своїх філій. На ТКР регіональних управлінь обліковуються ресурси філій загалом без виділення внеску конкретно кожного. Модель орієнтована на розгалужену мережу філій регіонального рівня з можливістю запровадження ВПС в межах лише регіону.
Шоста модель. Дана модель є розвитком четвертої, розповсюджується на віртуальний банківський регіон і рекомендується для банківських установ з трьохрівневою організаційною структурою. Всі банківські установи системи є учасниками СЕП НБУ і мають АРМ-3. В РРП відкриваються технічні коррахунки для головного банку, регіональних відділень та філій. Головний банк встановлює ліміти своїм регіональним управлінням, а регіональні управління підлеглим філіям. На початок операційного дня ТКР приймається рівним нулю на рівні регіонального управління та філій. Головному та регіональним банкам в РРП відкриваються коррахунки на яких обліковуються відповідно ресурси регіональних управлінь та філій без внеску конкретно кожного. Шоста модель може використовуватись банківськими системами, що мають до 200 філій у випадку, коли головний банк не має змоги безпосередньо управляти роботою філій і не може дозволити створення власної ВПС.
Сьома модель. Сьома модель є симбіозом третьої та четвертої моделей і поширюється на віртуальний банківський регіон. Всі установи системи є учасниками СЕП НБУ і мають свої АРМ-3. Всім установам банківської системи в РРП відкриваються свої ТКР, а головному банку ще й консолідований коррахунок. Головний банк може виконувати початкові платежі від імені своїх філій, як у третій моделі. Головний банк має можливість управляти ресурсами на рівні філіалів, надає самостійність філіям при проведенні масових платежів невеликими сумами і контролює платежі на великі суми. Управління філіями реалізовано з допомогою файлу типу ^M – бізнес-правил, що дозволяють:
- заборону виконання початкових платежів
- заборону відкриття та закриття особових рахунків
- обмеження сум конкретних платежів
- обмеження суми обігу за операційний день
- обмеження по заданому значенню залишку
- обмеження на відправника або отримувача платежів.
Файл бізнес-правил головним банком відправляється і має бути обов’язково сквитованим філією і тільки після цього можна посилати слідуючий набір бізнес правил.
Життєвий цикл ІС.
ЖЦ ІС – сукупність стадій, що проходить ІС аж до моменту утилізації засобів та мети, що були необхідні для створення ІС ( ГОСТ 34.601-90, ДСТУ 2941-94 – Система обробки інформації).
Стадії створення ІС – одна з частин процесу створення ІС, яка встановлена нормативними документами та закінчується випуском документації на ІС чи виготовленням несерійних компонентів ІС або прийомкою ІС в промислову експлуатацію.
Етап створення ІС – є частиною стадії створення ІС, виділеної з міркувань єдності характеру робіт та кінцевого результату чи спеціалізації виконавців
Модель ЖЦ – це опис послідовності дій (стадій, етапів), що мають виконуватися для створення високоякісних ІС. На сьогодні найбільш відомі моделі ЖЦ це:
I. каскадна модель
II. V-подібна модель
III. еволюційна модель прискореного прототипуваня
IV. модель швидкої розробки додатків
V. спіральна модель
Методологія передбачає використання певної технології створення ІС, підтримуючих її стандартів, методів й інструментальних засобів, що забезпечують иконання процесів ЖЦ.
Кожна методологія має задовільняти такі вимоги:
1. підтримувати повний ЖЦ ІС
2. забезпечувати гарантоване досягнення мети
3. забезпечувати можливість поділу великих проектів на ряд підпроектів з наступною інтеграцією резкльтатів
4. передбачити можливість ведення робіт з проектування групами в 3-7чол.
5. давати можливість керування проектом, ведення ерсій проекту, випуски проектної документації
6. забезпечувати належність виконання проекту від засобів реалізації системи: ОС, СКБД, середовищ програмування.
Призначення діаграм хореографій в BPMN
В
ідображають взаємодію (обмін повідомленнями між учасниками)
Підпроцес містить деталізацію хореографії, що включає декілька взаємодій. Може містити також маркер множинності для учасників, який показує , що декілька учасників одного типу приймають участь у хореографії. Призначення діаграм діалогів BPMN надають огляд комунікацій між учасниками. Діаграми діалогів можна створювати і обробляти в настільному клієнта PowerDesigner, в PowerDesigner Web вони доступні тільки для читання.
Стрілки в UML
Існує декілька основних типів відношень, а саме: залежність; асоціація; узагальнення; реалізація.
Відношення залежності - це односпрямоване відношення між двома сутностями, при якому зміна однієї сутності (первин-ної) викликає зміни семантики іншої, залежної, сутності.
Серед стереотипів відношень залежності можна назвати: derive, extend, include, owner, refine. Найчастіше використову-ються стереотипи extend та include. «Еxtend» (розширення) — використовується, коли розширюючий варіант використання доповнює базовий у певних точках розширення (які визнача-ються у базовому варіанті).
Відношення асоціації — це структурне двонаправлене відно-шення між об’єктами.
Позначка одиниця 1 на лівому кінці лінії асоціації на рис.11.3 означає, що в двонаправленому відношенні бере участь один екземпляр об’єкта, що знаходиться зліва. Одини-ця і зірочка (1..*) на правому кінці лінії означає «одиниця чи більше». Якщо один кінець лінії асоціації позначений одини-цею (1), то позначка на іншому кінці ліній називається кратні-стю асоціації. Кратність правого кінця асоціації, показаної на рис. 11.3, дорівнює одиниці чи більше.
На лінії асоціації можна також задати кратність, яка дорівнює одиниці (1), можна вказати діапазон кратності: нуль чи одиниця (0..1), багато (0..*).
Відношення «Узагальнення» — це односпрямоване відношен-ня, яке інакше ще називається «нащадок—батько». «Нащадок» успадковує структуру і поводження свого «бать-ка». Стрілка завжди вказує на «батька».
Відношення «реалізація» (rearization) — це семантичне односп-рямоване відношення, що може встановлюватися, по-перше, між інтерфейсами і реалізуючими їх класами чи компонен-тами.
Характеристика функціональної підсистеми «Управління роздрібними операціями» в АБС.
Сучасна АБС дозволяє підтримувати та реалізовувати широкий спектр функцій, які практично охоплюють всі банківські операції, що дозволяє швидко і якісно обслуговувати клієнтів. АБС складається з цілого ряду функціональних підсистем, що тісно інформаційно і функціонально пов’язані між собою. Схема функціональної структури АБМ представлена на рис..
Ядром АБС є і відповідно обов’язковою підсистемою є підсистема «Операційний день банку» (ОДБ). В ОДБ виконуються обліково-операційні роботи і обробляються різні платіжні документи, а також формуються інформаційні повідомлення, дебетові та інформаційні запити. Документи в ОДБ можуть надходити в електронному вигляді через систему „Клієнт-банк” чи в традиційно кур’єрським способом у вигляді паперових документів. Основними первинними документами ОДБ є платіжні та касові документи.
Підсистема «Управління касою» відноситься до фронт-офісних підсистем банку, вона автоматизує бізнес-процеси, операції пов’язані з готівковими коштами. В підсистемі виконується автоматизація обліку з прийому та видачі готівки через касу банку та облік роботи обмінних валютних пунктів.
В комерційних банках, що мають дозвіл на виконання операцій з іноземною валютою має функціонувати підсистема «Управління валютними операціями». Основні функції цієї підсистеми такі:
прогнозування курсів валют;
облік біржових та внутрішньобанківських валютних операцій;
облік ділінгових валютних операцій за угодами FOREX, SWAP і Forward та оцінка ділінгових контрактів;
розрахунок та утримання комісійної плати з клієнтів;
робота з системою SWIFT;
купівля та продаж валюти за замовленнями клієнтів;
контроль імпортно-експортних операцій клієнтів банку;
аналіз та контроль валютної позиції банку;
формування обов’язкової зовнішньої, внутрішньої та клієнтської звітності.
Підсистема "Роздрібного обслуговування клієнтів" – це відносно новий напрям в розширенні функціональних можливостей АБС. Ця підсистема необхідна тим банкам, які окрім обслуговування корпоративних клієнтів обслуговують широкі верстви населення
Проектування внутрішньомашинної інформаційної бази.
Внутрішньомашинна інформаційна база — це частина ІБ, яка являє собою сукупність даних на машинних носіях, використовуваних в ІС.
Внутрішньомашинна ІБ даної інформаційної системи організується у вигляді спеціальних масивів даних, які можна умовно поділити на оперативну та нормативно-довідкову інформацію. Уся ця інформація знаходиться на ЖМД, але в будь-який момент може бути зроблено архів.
При розробленні внутрішньомашинної інформаційної бази особливу увагу приділяють тому, щоб дані, які зберігаються в ній, можна було широко використовувати і щоб способи використання даних можна було легко змінити. Для забезпечення гнучкості використання даних, їх ефективного використання в даному проекті пропонується файлова організація внутрішньомашинної ІБ. Характерною особливістю запропонованої інформаційної бази є наявність нормативно-довідкових даних.
Масиви нормативно-довідкової інформації можуть використовуватися при реалізації введення даних, для контролю введеної інформації на наявність її у файлах НДІ.
Організація інформаційного забезпечення даної ІС пов’язана з розробленням системи класифікації та кодування, організацією збирання та передавання інформації, розроблення зовнішньо- та внутрішньомашинної інформаційної бази, а також із формуванням вихідних даних.
Проектування внутрішньомашинної інформаційної бази може здійснюватись двома способами:
1) проектування бази даних;
2) проектування структури файлів.
При описі структури внутрішньомашинної інформаційної бази наводять перелік баз даних і масивів та логічні зв'язки між ними. Для масиву інформації вказують логічну структуру масиву чи дають посилання на документ "Опис масиву інформації".