Ролі :
Пули (учасники) і доріжки відображають розподіл обов'язків. Пул або доріжка позначає організацію, роль або систему. Доріжки дають змогу ієрархічно поділяти пули та інші доріжки.
Потік повідомлень описує інформаційний потік між учасниками процесу. Потік повідомлень може приєднуватися до пулів, дій чи подій-повідомлень.
Порядок обміну повідомленнями може бути заданий за допомогою потоку повідомлень і потоку керування
Провести аналогії між діаграмами UML та BPMN
UML (англ. Unified Modeling Language - уніфікована мова моделювання) - мова графічного опису для об'єктного моделювання в області розробки програмного забезпечення, моделювання бізнес-процесів, системного проектування та відображення організаційних структур.
UML є мовою широкого профілю, це - відкритий стандарт, який використовує графічні позначення для створення абстрактної моделі системи, званої UML-моделлю. UML був створений для визначення, візуалізації, проектування та документування, в основному, програмних систем. UML не є мовою програмування, але на підставі UML-моделей можлива генерація коду.
BPMN (англ. Business Process Model and Notation, нотація та модель бізнес-процесів) — система умовних позначень (нотація) для моделювання бізнес-процесів. Розроблена Business Process Management Initiative (BPMI) та підтримується Object Management Group після їх злиття в 2005 році. Остання версія BPMN — 2.0, що була прийнята у січні 2011 року.
Єдиний формальний зв'язок між UML і BPMN полягає в тому, що OMG підтримує обидві відкриті стандарти.
Крім того, обидва є стандартизованими графічними позначеннями, які дозволяють моделювати бізнес-процеси таким чином: (1) BPMN призначений для моделювання бізнес-процесів; (2) UML має 14 типів діаграм, де діаграма активності підходить для моделювання бізнес-процесів.
відмінності
Фокусна відмінність між UML і BPMN полягає в тому, що UML є об'єктно-орієнтованим, в той час як BPMN використовує орієнтований на процес (process-oriented) підхід, більш відповідний в межах області бізнес-процесів (business process domain).
Таким чином, BPMN стає лідером і стандартом де-факто при моделюванні бізнес-процесів.
Характеристика функціональної структури АБС.
Функціональна структура АБС. Автоматизована банківська система повинна забезпечувати:
автоматизацію внутрібанківської діяльності, і насамперед внутрiбанкiвських операцій, пов’язаних з обробкою платіжних та інших документів у тих підрозділах банківської установи, які працюють безпосередньо з клієнтами;
автоматизацію виконання мiжбанкiвських розрахунків та інших зовнішньо-банківських операцій;
автоматизацію фінансових операцій в межах міжнародного банківського бізнесу.
Зрозуміло, що автоматизація цих процесів повинна доповнювати одна одну і бути взаємозв’язаними. Автоматизація кожного з них має свою специфіку й особливості і є доволі складною проблемою з високим рівнем автономності.
Зосередимо увагу на автоматизації внутрібанківської діяльності на рівні комерційних банків. Огляд АБС показав, що вона відрізняються одна від одної як за структурою, так і за набором функціональних задач. Зараз немає типової структури АБС, якою б керувались банки при розробці своїх систем, практично відсутні елементи стандартизації та уніфікації банківських технологій.
Вивчення структур різних банківських систем та проведене певне їх узагальнення дають змогу виділити такі основні функціональні підсистеми АБС: операційний день банку (ОДБ), управління кредитними ресурсами (Кредити), управління валютними операціями (Валютні операції), управління депозитами (Депозити), управління цінними паперами (Цінні папери), управління касою (Каса), внутрібанківський облік (Внутрішній облік), управління розрахунками з використанням пластикових карток (Карткові операції), звітність, аналіз діяльності банку (Аналіз).
Компонентне проектування ІС.
Проектування ІС - це процес визначення архітектури, набору компонентів, їх інтерфейсів, інших характеристик системи і кінцевого складу програмного продукту.
В об'єктно-орієнтованому проектуванні ключову роль відіграє спадкування, поліморфізм й інкапсуляція, а також абстрактні структури даних і відображення об'єктів.
Підходи, орієнтовані на структури даних використовуються для подання вхідних і вихідних даних структурними діаграмами.
Метод UML призначений для опису сценаріїв роботи проекту у наочному діаграмному вигляді.
Компонентне проектування ґрунтується на використанні готових компонентів (reuse) з визначеними інтерфейсами і їх інтеграції в конфігурацію, як основи розгортання компонентної системи для її функціонування в операційному середовищі.
Компонентне розроблення - це метод побудови ПЗ як композицій готових компонент з конструкцій за каталогом.
Повторне використання - це використання для нових розроблень будь-яких фрагментів інформації, здобутих у процесі розроблення інших ІС.
Повторно використовувані компоненти - елементи знань про минулий досвід розроблення систем програмування, які можна використовувати для створення нових ІС без участі їх розробників.
Тому нині активно розвивається напрямок водночас і науковий, і інженерний, який названо повторним використанням або компонентним розробленням програм.
Логічні оператори в BPMN.
BPMN (Business Process Model and Notation/нотація і модель бізнес-процесів).
BPMN є системою умовних позначень (нотація) для моделювання бізнес-процесів, або функкціональності систем.
Виключаюче «або», кероване даними ( data-based exclusive gateway). - для розгалуження потік управління спрямовується по одній вихіднії гілці, для синхронізації очікує завершення однієї вхідної гілки.
Виключаюче «або», кероване подіями (event-based exclusive gateway) направляє потік управління лише з тієї вихідної гілки, на якій першій відбулася подія. Після оператора даного типу можуть слідувати тільки події або дії-обробники повідомлень.
Оператор «і» (parallel event-based gateway)-для розгалуження, розділяє один потік управління на кілька паралельних. При цьому всі вихідні гілки активуються одночасно. Якщо оператор використовується для синхронізації, то він очікує завершення виконання всіх вхідних гілок і лише потім активує вихідний потік.
Включаюче «або» (inclusive gateway) активує одну або більше вихідних гілок. Якщо оператор використовується для синхронізації, то він очікує завершення виконання однієї вхідної гілки і активує вихідний потік.
Складний оператор (complex gateway) має кілька умов, в залежності від виконання яких активуються вихідні гілки.
Паралельний шлюз (Parallel Gateway )розгалуження і з'єднання.
Взаємозв’язок між діаграмами варіантів використання та діаграмами послідовності в UML
Діаграми варіантів використання, або прецендентів (Use-Case Diagrams) – це графічне представлення поведінки системи – варіантів її використання.
Застосовуються діаграми варіантів використання при проектуванні системи на стадії аналізу, щоб охопити системні вимоги і зрозуміти, як система повинна працювати.
Кожний варіант може описуватися окремо, на окремій діаграмі, або ж ряд варіантів можуть бути зведені в єдину діаграму.
Діаграми варіантів використання можуть містити:
Акторів („ролі” зовні системи);
Варіанти використання (визначають можливості системи);
Границі системи:
Відношення між акторами і варіантами використання в системі:
Між актором та варіантом використання може показуватися лише асоціація. Напрямок стрілки на асоціації вказує в даному випадку хто є ініціатором зв’язку (деколи ЩЕ генералізація)
Між варіантами використання вказується відношення залежності (підтипи include, extend).
Діаграми послідовності (Sequence Diagrams) є одним з двох видів діаграм взаємодії (interaction). Вони представляють собою моделі, що описують поведінку взаємодіючих груп об’єктів в рамках одного варіанту використання.
На діаграмах послідовності використовуються наступні елементи:
Об’єкти - зображаються прямокутниками по горизонталі у верхній частині вікна ті об’єкти, які беруть участь у реалізації варіанта використання, що розглядається.
Лінія життя об’єкта – зображається вертикальною пунктирною лінією, що відходить від об’єкта вниз, представляє собою його житєвий цикл в процесі взаємодії.
Прямокутник активності – видовжений до низу прямокутник малюється на лінії життя об’єкта, щоб показати період часу, на протязі якого об’єкт є активним (якщо він не вказується – діаграми складніше розуміти).
Повідомлення - представляється стрілкою між лініями життя двох об’єктів та помічається іменем. За часом більш ранніми є ті повідомлення, що знаходяться вище.
Взаємозвязок: взаємодія об’єктів контролюється подіями, які відбуваються в сценарії і які стимулюють об’єкти для посилання одне одному повідомлень. Повідомлення позначаються на діаграмі стрілками, над якими можуть вказуватися зміст повідомлення, параметри, які воно передає та порядковий номер повідомлення в сценарії. Зазначимо, що вказані на діаграмі повідомлення мають узгоджуватися з видимими операціями відповідних класів.
Автоматизація технології судочинства і судового діловодства.
Інформатизація органів судової влади вимагає створення типових інформаційних систем, основу структури яких складають автоматизовані робочі місця працівників судів, об’єднані у локальні обчислювальні мережі.
Значну частину свого часу суддя неминуче витрачає не лише на свою головну діяльність — підготовку й ухвалення юридичного рішення, а й на рутинну багаторазово повторювану роботу — написання або друкування однакових процесуально необхідних словесних оборотів, що повторюються в кожному однотипному документі. З появою персональної комп’ютерної техніки для цих задач почали використовувати текстові редактори (зокрема, «MS Word»). При цьому документ, ретельно підготовлений і взятий як зразок, надалі доповнюється необхідними для певної справи конкретними даними — замінюються прізвища, посилання на процесуальні статті тощо.
Однак створення повноцінних спеціалізованих шаблонів для більшого підвищення ефективності роботи, вимагає майже професійних навичок з програмування і недоступне для обтяженого роботою судді. З іншого боку, голова суду та його апарат (помічники, канцелярія, експедиція, архів, секретаріат суду) зобов’язані забезпечити чітке проходження справ через усі підрозділи суду, передачу справ суддям і від суддів у канцелярію та інші операції, докладно регламентовані інструкцією з діловодства в суді. Цей процес дуже чутливий до неминучих помилок.
Усе сказане зумовлює необхідність інтеграції технологій діловодства в єдиний процес, що не тільки підвищить рівень організації праці робітників судів, а й прискорить розгляд справ у суді на будь-якій стадії процесу, збільшить період часу для аналізу справ, надасть можливість більш повного та оперативного оброблення статистичних даних, забезпечить ефективний пошук інформації, її надійність і конфіденційність, а також створить передумови для удосконалення контролю керівництва за діяльністю підлеглих підрозділів і суддів та своєчасного поширення судової практики, пов’язаної у першу чергу з постійними змінами норм процесуального і матеріального права.
Введення інформації здійснюється за допомогою вбудованого редактора — заповнення шаблонів процесуальних документів забезпечується вибором усієї необхідної інформації з можливістю подальшого редагування одержаного тексту документа. Наявні також інструменти зміни шаблонів та їх поповнення.
Кожне АРМ також оснащене:
· засобами автоматичного формування документів будь-якої форми, створюваних у процесі руху справи, на основі раніше введеної інформації;
· засобами контролю процесуального і логічного характеру;
· різного роду довідниками, які містять законодавчу і нормативну інформацію.
АРМ секретарів канцелярій містять функції одержання статистичної звітності за будь-який період за визначеними формами з можливістю їхньої подальшої модифікації без залучення програмістів, видачі довідок і запитів за довільною формою для всіх користувачів, що мають доступ до цієї інформації.
Міжнародні стандарти, що регламентують життєвий цикл ІС
ISO/IEC 12207 – визначає структуру життєвого циклу, що містить процеси, дії і задачі, які повинні бути виконані під час створення ПЗ.
Структура ЖЦ ПЗ за даним стандартом базується на трьох групах процесів:
1. основні процеси (придбання, поставка, розробка, експлуатація, супровід);
2. допоміжні процеси, що забезпечують виконання основних процесів (документування, управління конфігурацією, забезпечення якості, верифікація, атестація, оцінка, аудит, рішення проблем);
3. організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка й поліпшення самого ЖЦ, навчання).
ISO/IEC 15504 (SPICE) – визначає правила оцінки процесів життєвого циклу ПЗ і їх можливостей, спирається на модель CMMI і більше орієнтований на оцінку процесів і можливостей їх покращення.
В якості основи для оцінки процесів визначає деяку базову модель. У ній виділені категорії процесів, процеси і види діяльності.
ISO/IEC 12207:1995 – визначає загальну структуру життєвого циклу ПЗ у вигляді 3 ступінчастої моделі: процеси - види діяльності - завдання
Стандарт описує елементи в термінах їх цілей і результатів, але чітко структура звязків не описується.
ГОСТ 34.601-90: формування вимог до ІС; розробка концепції ІС; ТЗ; ескізний проект; технічний проект; робоча документація; введення в дію; супровід ІС.
ДСТУ 3918-1999 «Процеси ЖЦ ПЗ» - вводить добре визначену систему понять для процесів ЖЦ ПЗ, яка може використовуватись в індустрії ПЗ. Містить визначення процесів, дій і задач, які повинні виконуватися впродовж придбання ІС, яка містить ПЗ, а також під час розробки, експлуатації та супроводу ПЗ.
Події в BPMN.
BPMN є системою умовних позначень (нотація) для моделювання бізнес-процесів, або функкціональності систем.
Події (events) - один з трьох об'єктів потоку управління, зображуються кружечком і означають яку-небудь подію. Події ініціюють дії або є їх результатами. Поділяються на:
Об’єктні методології проектування ІС.
Об'єктні методології розглядають предметну область, що моделюється, як набір взаємодіючих об'єктів - виробничих одиниць. Об'єкт визначається як предмет або явище, що має чітко визначену поведінку. Метою застосування даної методології є виділення об'єктів, що становлять організацію, і розподіл між ними відповідальностей за виконувані дії.
Об'єктне проектування передбачає створення типового проекту ІC для узагальненого об'єкта, виділеного з групи об'єктів як еталон. При цьому група однотипних об'єктів може бути невеликою (наприклад, для годинникових заводів).
За типового проектування застосовуються: стандартні засоби ОС; типові компоненти — ТПР, ППП, типові АСУ (наприклад, АСУ «СИГМА», АСУ «ЛЬВІВ» та ін.); конкретні інструментальні засоби.
Об'єктно-орієнтоване програмування - це метод програмування, заснований на поданні програми у вигляді сукупності взаємодіючих об'єктів, кожен з яких є екземпляром певного класу, а класи є членами певної ієрархії наслідування.[3]. Програмісти спочатку пишуть клас, а на його основі при виконанні програми створюються конкретні об'єкти (екземпляри класів). На основі класів можна створювати нові, які розширюють базовий клас і таким чином створюється ієрархія класів.
На думку Алана Кея, розробника мови Smalltalk, якого вважають одним з «батьків-засновників» ООП, об'єктно-орієнтований підхід полягає в наступному наборі основних принципів:
Все є об'єктами.
Всі дії та розрахунки виконуються шляхом взаємодії (обміну даними) між об'єктами, при якій один об'єкт потребує, щоб інший об'єкт виконав деяку дію. Об'єкти взаємодіють, надсилаючи і отримуючи повідомлення. Повідомлення — це запит на виконання дії, доповнений набором аргументів, які можуть знадобитися при виконанні дії.
Кожен об'єкт має незалежну пам'ять, яка складається з інших об'єктів.
Кожен об'єкт є представником (екземпляром, примірником) класу, який виражає загальні властивості об'єктів.
У класі задається поведінка (функціональність) об'єкта. Таким чином усі об'єкти, які є екземплярами одного класу, можуть виконувати одні й ті ж самі дії.
Класи організовані у єдину деревоподібну структуру з загальним корінням, яка називається ієрархією успадкування. Пам'ять та поведінка, зв'язані з екземплярами деякого класу, автоматично доступні будь-якому класу, розташованому нижче в ієрархічному дереві.
Характеристика функціональної підсистеми «Управління кредитними ресурсами» в АБС.
Автоматизована банківська система — це система, яка функціонує на основі
ЕОМ та інших технічних засобів, що забезпечують процеси збору,
реєстрації, передачі, обробки, збереження та актуалізації даних для
розв’язання завдань управління банківською діяльністю.
В межах підсистеми «Управління кредитними ресурсами банку»працівники кредитного відділу банку мають можливість виконувати такі основні функції:
· аналіз фінансового стану позичальника, визначення його кредитоспроможності та оцінка ризику при кредитуванні;
· формування та облік кредитних договорів;
· ведення та коригування розпоряджень на оплату кредитів;
· ведення та коригування строкових зобов’язань на погашення кредиту;
· ведення та коригування процентних ставок та графіків оплати процентів по кредитному договору;
· нарахування процентів по кредиту та облік їх сплати;
· облік та контроль погашення кредитної заборгованості;
· аналіз кредитного портфеля, класифікація кредитів та визначення розміру резервування.
Підсистема «Управління кредитними ресурсами» має бути інтегрована з іншими функціональними підсистемами банку, зокрема з ОДБ, у якій виконують бухгалтерські проведення при наданні кредиту та при погашенні суми основного боргу і відсотків по ньому
Поняття інформаційного забезпечення інформаційних систем.
ІЗ (ІЗ) - сукупність форм документів, нормативної бази та реалізованих рішень щодо обсягів, розміщення і форм існування інформації, яка використовується в інформаційній системі при її функціонуванні.
Вимоги до ІЗ:
- воно має бути достатнім для виконання всіх функцій ІС, які автоматизуються.
- для кодування інформації тільки в цій ІС, повинні бути застосовані наявні у замовника ІС класифікатори.
- ІЗ ІС має бути суміщене з інформаційним забезпеченням систем, які взаємодіють з нею, за змістом, системою кодування, методами адресації, форматами даних і формами подання одержаної і виданої інформаційною системою інформації.
- форми подання вихідної інформації ІС повинні бути погоджені із замовником (користувачем) системи.
- форми документів і відеокадрів, які вводяться, виводяться чи коригуються через термінали ІС, слід погоджувати з відповідними технічними характеристиками терміналів.
- терміни і скорочення у вихідних повідомленнях мають бути загальноприйнятими в цій проблемній сфері й погоджені із замовником.
- у ІС необхідно передбачити обов’язкові заходи щодо контролю й оновлення даних в інформаційних масивах ІС, оновлення масивів після відмови будь-яких технічних засобів ІС, а також контролю ідентичності однойменної інформації в базах даних.
Дії в BPMN.
BPMN є системою умовних позначень (нотація) для моделювання бізнес-процесів, або функкціональності систем.
Дії (activities) - один з трьох об'єктів потоку управління, зображуються прямокутниками із закругленими кутами.
Завдання - це одиниця роботи, елементарна дія в процесі. Можуть бути маркери (служба,скрипт, обмін повідомленнями, ручна/користувацька/бізнес-правило).
Множинні екземпляри - показують, що одна дія виконується багаторазово, по одному разу для кожного об'єкта ( можуть виконуватися паралельно або послідовно).
Циклічна дія – виконується, поки умова циклу вірна. Умова циклу може перевірятися до або після виконання дії.
Розгорнутий підпроцесс – є складним процесом і містить в собі власну діаграму бізнес-процесів.
Згорнутий підпроцесс - також є складною дією, але приховує деталі реалізації процесу.
Ad-hoc-підпроцес містить завдання, що виконуються до тих пір, поки не виконана умова завершення підпроцеса.
Сутність та історія об’єктно-орієнтованого підходу до проектування інформаційної системи.
Об'єктно-орієнтований підхід використовує об'єктну декомпозицію. При цьому структура системи описується в термінах об'єктів і зв'язків між ними, а поведінка системи описується в термінах обміну повідомленнями між об'єктами. Кожен об'єкт системи має свій власний поведінкою, що моделює поведінку об'єкта реального світу.
Концептуальною основою об'єктно-орієнтованого підходу є об'єктна модель. Її основними поняттями є: об'єкти та атрибути, ціле і частина, класи і екземпляри.
В даному визначені є три основні частини:
1. в якості базових операцій використовуються об’єкти, а не алгоритми;
2. кожний об’єкт є екземпляром якогось визначеного класу;
3. класи організовані ієрархічно.
Об’єкт складається з трьох частин:
1. Ім’я;
2. Стан (зберігається від звернення до звернення, змінюється лише при виклику методів даного об’єкта);
3. Методи (операції).
Інтерфейс об’єкту з його середовищем визначений цілком його методами, т.я. до його станів немає іншого доступу ззовні.
Об’єкт може посилати повідомлення іншим об’єктам і приймати їх. Повідомлення — дані визначеного типу, що передаються від відправника до одержувача, ім’я якого вказують у повідомленні. Одержувач реагує або не реагує на повідомлення виконанням деякої операції, методі, ім’я якого також вказують. Об’єкт є представником реальної сутності — реального об’єкту, процесу, ситуації, яка:
1 2 3 4 5 6 7 8 9 ... 12