Розробка інформаційної системи "Періодичні видання"

Размещено на http://www.allbest.ru

Размещено на http://www.allbest.ru

Вступ

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

· складність опису (велика кількість функцій, процесів, елементів даних і складні взаємозв'язки між ними), що вимагає ретельного моделювання й аналізу даних і процесів;

· наявність сукупності компонентів (підсистем), що знаходяться у тісній взаємодії, виконують певні локальні задачі і цілі функціонування (наприклад додатків, пов'язаних з обробкою трансакцій і рішенням регламентних задач, додатків аналітичної обробки (підтримки прийняття рішень), які використовують нерегламентовані запити до даних великого обсягу);

· відсутність прямих аналогів, що обмежує можливість використання типових проектних рішень і прикладних систем;

· необхідність узгодження існуючих додатків з новими розробками;

· функціонування в неоднорідному середовищі на декількох апаратних платформах;

· різнорідність рівня кваліфікації і сформованих традицій використання певних наборів інструментальних засобів у групах розробників;

· істотна тривалість проекту - обумовлена, з одного боку, обмеженими можливостями колективу розробників; з іншого боку, масштабами організації-замовника і різним ступенем готовності окремих її підрозділів до впровадження ІС.

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

1. Предметна область

1.1 Опис предметної області

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

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

Суб'єкт моделювання - дія автоматизованої системи в межах даного агенства.

1.2 Функції вирішуваної задачі

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

Задача проектування системи «Періодичні видання» повинна виконувати такі функції:

- представлення послуг;

- видача прайс-листа;

- оформлення документів;

- видача квитанцій;

Дана база повинна забезпечити зручний та об'єктивних підхід до використання автоматизованої системи вибору послуги за даною тематикою.

2. Інструментальне середовище BPwin

2.1 Загальна характеристика BPwin

CASE - середовище верхнього рівня BPwin - це інструмент візуального моделювання ІС, що дозволяє:

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

Перевірити модель на відповідність стандартам ISO9000. Для вітчизняних підприємств сертифікація по ISO 9000 - це перепустка на міжнародний ринок, а також дієвий засіб для ефективного поліпшення роботи всього підприємства;

Спроектувати структуру інформаційних потоків, а відповідно, і модернізувати організаційну структуру підприємства;

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

Знизити витрати і підвищити продуктивність;· Виявити і виключити зайві або неефективні операції;

Підвищити гнучкість і ефективність.

Все це дозволить отримати цілісне уявлення про те, як працює підприємство, починаючи від структурного підрозділу і закінчуючи підприємством в цілому. Якщо компанія займається системною інтеграцією або постачанням готових рішень в області ІТ, модель бізнес-процесів - це найкращий засіб обґрунтувати, як вплинуть інвестиції в ІТ на ефективність діяльності підприємства. BPwin входить в сімейство продуктів AllFusion компанії Computer Associates під ім'ям AllFusion Process Modeler і призначений для підтримки всіх стадій життєвого циклу розробки ІС. - У лінійку продуктів AllFusion Modeling Suite крім BPwin для підтримки всіх стадій розробки програмного забезпечення, входять CASE-засобів ERwin, BPwin, ModelMart, Paradigm Plus, ERwin Examiner та засоби управління проектами. Спільне застосування цих продуктів забезпечує міцний фундамент для побудови, розгортання і керування додатками. При цьому не накладаються обмеження на вибір базових технологій, методів і платформ розробки. AllFusion Modeling Suite пропонує моделювання та управління процесами, проектами, змінами, конфігураціями.BPwin - інструмент моделювання, який використовується не тільки для аналізу та документування, але і реорганізації складних процесів. BPwin відповідає вимогам до інструментів для розробки ІС, так як дозволяє чітко документувати різні дії, які необхідно вжити, а також способи їх здійснення і необхідні для цього ресурси.

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

BPwin автоматизує завдання, пов'язані з побудовою моделей, забезпечуючи семантичну строгість, необхідну для гарантування правильності результатів, а також цілісність і несуперечність моделі, які гарантуються застосуванням методологій IDEF 0, IDEF 1 X (Data Flow Diagram) і IDEF 3 (Work Flow Diagram). Кожна з цих трьох нотацій, підтримуваних в BPwin, дозволяє розглянути різні сторони діяльності підприємства і комплексно описати предметну область з трьох різних, але взаємопов'язаних точок зору.

BPwin може генерувати звіти безпосередньо у форматі MS Excel і Word для подальшої обробки і використання в інших додатках. Зв'язок з ERwin (моделювання даних в стандарті IDEF1X) дозволяє скоротити час проектування і розробки складних інформаційних систем. Для системних аналітиків тісна інтеграція BРwin з інструментом проектування баз даних відкриває унікальні можливості по створенню комплексних систем, в яких ERwin служить для опису інформаційних об'єктів системи, в той час як BPwin відбиває функціональні особливості предметної області. Пов'язуючи сутності і атрибути моделі даних з інформацією про виконуваних діях, Ви можете продовжити аналіз процесів на новому рівні з одночасною перехресної перевіркою моделей процесів і даних.

Основні характеристики BPwin:

Розвинута методологія функціонального моделювання на основі IDEF0;

Потужні редактори для опису операцій, зв'язків і обчислення витрат на виконання робіт;

Ієрархічна структура діаграм, що полегшує послідовне уточнення елементів моделі;

Контекстні діаграми для опису меж системи, області дії, призначення об'єктів;

Декомпозиційні діаграми для опису особливостей взаємодії різних процесів;

Розширені можливості по підтриманню посилальної цілісності;

Підтримка методології IDEF3;

Експорт моделей в засоби імітаційного моделювання;

Інтеграція та зв'язок із засобом проектування баз даних ERwin (методологія IDEF1X);

Підтримка властивостей, визначених користувачем. Опис моделей може бути розширено за рахунок властивостей, визначених користувачем, включаючи мультимедійні документи;

Методології, які використовуються в BPwin

BPwin підтримує три методології структурного аналізу і моделювання систем - IDEF0, IDEF3, DFD. В процесі створення бізнес-процесу на будь-якій вітці моделі можна переключитись на будь яку із методологій і створити змішану модель.

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

Методологія DFD включає такі поняття як внутрішня ссилка і сховище даних. Це робить її більш зручною в порівнянні з IDEF0 для моделювання програмного забезпечення і систем документообігу.

Методологія IDEF3 включає елемент «перехрестя», що дозволяє описати логіку взаємодії компонентів системи.

2.2 Методологія IDEF0.

Методологія IDEF0 передбачає побудову ієрархічної системи діаграм - одиничних описів фрагментів системи. Спочатку проводиться опис системи в цілому і її взаємодії з навколишнім світом (контекстна діаграма), після чого проводиться функціональна декомпозиція - система розбивається на підсистеми і кожна підсистема описується окремо (діаграми декомпозиції). Потім кожна підсистема розбивається на більш дрібні і так далі до досягнення потрібного ступеня подробиці.

Кожна IDEF0-діаграм а містить блоки і дуги. Блоки зображують функції модельованої системи. Дуги пов'язують блоки разом і відображають взаємодії і взаємозв'язку між ними.

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

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

Кожна сторона блоку має особливе, цілком певне призначення. Ліва сторона блоку призначена для входів, верхня - для управління, права - для виходів, нижня - для механізмів. Таке позначення відображає певні системні принципи: входи перетворюються у виходи управління обмежує або наказує умови виконання перетворень, механізми показують, що і як виконує функція.

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

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

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

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

2.3 Методологія IDEF3

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

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

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

Основою моделі IDEF3 служить так званий сценарій бізнес-процесу, який виділяє послідовність дій або підпроцесів аналізованої системи. Оскільки сценарій визначає призначення і межі моделі, досить важливим є підбір відповідного найменування для позначення дій. Для підбору необхідного імені застосовуються стандартні рекомендації по кращого використання дієслів і віддієслівних іменників, наприклад «обробити замовлення клієнта» або «застосувати новий дизайн».

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

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

2.4 Методологія DFD

Діаграми потоків даних (Data Flow Diagrams) представляють мережу пов'язаних між собою робіт. Їх зручно використовувати для опису документообігу та обробки інформації.

DFD описує:

- функції обробки інформації (роботи);

- документи (стрілки, arrow), об'єкти, співробітників або відділи, які беруть участь в обробці інформації;

- зовнішні посилання (external reference), які забезпечують інтерфейс з зовнішніми об'єктами, що знаходяться за межами модельованої системи;таблиці для зберігання документів (сховища даних, data store).

Для побудови діаграм DFD в BPwin використовується нотація Гейна-Сарсона.

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

Призначення процесу полягає в продукуванні вихідних потоків із вхідних у відповідності з дією, заданим ім'ям процесу. Фізично процес може бути реалізований різними способами: це може бути підрозділ організації (відділ), виконує обробку вхідних документів і випуск звітів, програма, апаратно реалізоване логічний пристрій і т.д. У полі імені вводиться найменування процесу у вигляді пропозиції з активним дієсловом у невизначеною формі (обчислити, розрахувати, перевірити, визначити, створити, отримати), за яким слідують іменники в знахідному відмінку, наприклад: "Ввести відомості про платників податків", "Видати інформацію про поточні витрати", "Перевірити надходження грошей". Кожен процес повинен мати унікальний номер для посилань на нього всередині діаграми. Цей номер може використовуватися спільно з номером діаграми для отримання унікального індексу процесу у всій моделі.

Сховище даних дозволяє на певних ділянках визначати дані, які будуть зберігатися в пам'яті між процесами. Фактично сховище являє «зрізи» потоків даних у часі. Інформація, яку воно містить, може використовуватися в будь-який час після її визначення, при цьому дані можуть вибиратися в будь-якому порядку. Накопичувач даних може бути реалізований фізично у вигляді ящика в картотеці, таблиці в оперативній пам'яті, файлу на магнітному носії і т.д. Сховище даних в загальному випадку є прообразом майбутньої бази даних, і опис зберігаються і ньому даних повинне бути пов'язане з інформаційною моделлю (ERD). Ім'я сховища має ідентифікувати його вміст, воно вибирається з міркування найбільшої інформативності для проектувальника. У випадку, коли потік даних входить у сховище або виходить з нього і його структура відповідає структурі сховища, він повинен мати те ж саме ім'я, яке немає необхідності відображати на діаграмі.

3. Проектування системи «Періодичні Видання»

3.1 Проектування моделі діяльності в BPwin

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

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

При створенні нової моделі виникає діалог, наведений на рис. 3.1. У даному діалозі вказано, створюється нова модель чи вона відкривається з файлу або з ModelMart, введено ім'я нової моделі і вибрано методологію, в якій вона буде будуватися.

Рис. 3.1. Створення нової моделі

Модель в Bpwin розглядається як сукупність робіт, кожна з яких оперує деяким набором даних. Робота зображується у вигляді прямокутників, дані - у вигляді стрілок. Якщо клацнути з кожного об'єкту моделі лівою кнопкою миші, з'являється спливаюче контекстне меню, кожен пункт якого відповідає редактору небудь властивості об'єкта.

Рис. 3.2. Діалог Properties for New Models

Для внесення імені роботи слід клацнути по роботі правою кнопкою миші, вибрати в меню Name і в діалозі, що з'явився внести ім'я роботи. Для опису інших властивостей роботи служить діалог Activity Properties (Рис. 3.3).

Рис. 3.3. Задання імені контекстної діаграми

Щоб описати предметну область моделі діяльності необхідно в діалоговому вікні Activity Properties перейти на вкладку Definition (Рис. 3.4.).

Рис. 3.4. Опис предметної області

3.2 Побудова контекстної діаграми

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

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

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

Вхід системи «Операції з нерухомістю» - Клієнт.

Вихід системи - Послуга.

Система керується:

Закон України;

Статут підприємства;

Ліцензія на представлення послуг;

Управлінська діяльність:

Дирекція;

Менеджер;

Вигляд контекстної діаграми зображено на Рис. 3.5.

Рис. 3.5. Контекстна діаграма

програмний контекстний візуальний діаграма

3.3 Діаграма декомпозиції першого рівня

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

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

В результаті виникає діалог Activity Box Count, в якому слід вказати нотацію нової діаграми і кількість робіт на ній.

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

Для зв'язування граничних стрілок входу, управління або механізму з відповідними роботами необхідно перейти в режим редагування стрілок, клацнути по наконечнику стрілки і клацнути по відповідній стороні роботи.

Рис. 3.6. Вибір кількості блоків діаграми декомпозиції

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

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

Для діаграми декомпозиції першого рівня необхідно визначити наступні функції:

Отримання бланку;

Заповнення бланку;

Присвоєння номеру підписки;

Отримання квитанцій;

Представлення послуг;

Вигляд діаграми декомпозиції першого рівня представлено на Рис. 3.7.

Рис. 3.7. Декомпозиція першого рівня

3.4 Діаграма декомпозиції другого рівня «Отримання бланку»

Для побудови діаграми декомпозиції другого рівня «Отримання бланку» необхідно визначити наступні функції:

Перевірка наявності послуги;

Введення інформації;

Видача даних;

Виконання запиту;

У процесі декомпозиції функціональний блок, який в контекстній діаграмі відображає систему як єдине ціле, піддається деталізації на іншій діаграмі. Функціональні блоки діаграми другого рівня (дочірньої - Child diagram) відображають головні підфункції функціонального блоку контекстної діаграми і називаються дочірніми блоками (Child Box). У свою чергу, функціональний блок-предок називається батьківським блоком (Parent Box), а діаграма, до якої він належить - батьківської діаграмою (Parent Diagram).

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

Вигляд діаграми декомпозиції другого рівня «Видача прайс-листа» зображений на Рис. 3.8.

Рис. 3.8. Декомпозиція другого рівня «Отримання бланку»

3.5 Діаграма декомпозиції другого рівня «Заповнення Бланків

Для побудови діаграми декомпозиції другого рівня «Заповнення Бланків» необхідно визначити наступні функції:

Видача Прикладу заповнення;

Перевірка на помилки;

Перевірка права власності;

Нотаріальне засвідчення;

Вигляд діаграми декомпозиції другого рівня «Заповнення Бланків » зображений на Рис. 3.9.



Рис. 3.9. Декомпозиція другого рівня «Заповнення Бланків»

3.6 Діаграма декомпозиції другого рівня «Присвоєння номеру підписки»

Для побудови діаграми декомпозиції другого рівня «Присвоєння номеру підписки» необхідно визначити наступні функції:

Перевірка даних клієнта ;

Перевірка № підписки видавництва;

Успішне заповнення даних;

Вигляд діаграми декомпозиції другого рівня «Видача звіту» зображений на Рис. 3.10.

Рис. 3.10. Декомпозиція другого рівня «Присвоєння номеру підписки»

3.7 Діаграма декомпозиції другого рівня «Отримання квитанцій про оплату»

Для побудови діаграми декомпозиції другого рівня «Отримання квитанцій про оплату» необхідно визначити наступні функції:

Звернення в касу;

Отриманні відповіді про оплату;

Вигляд діаграми декомпозиції другого рівня «Видача звіту» зображений на Рис. 3.11.

Рис. 3.11. Декомпозиція другого рівня «отримання квитанції про оплату»

3.8 Діаграма декомпозиції другого рівня «Представлення послуг»

Для побудови діаграми декомпозиції другого рівня «Представлення послуг» необхідно визначити наступні функції:

Успішне завершення;



Рис. 3.12. Декомпозиція другого рівня «Представлення послуг»

3.7 Побудова діаграми дерева вузлів

Діаграми, отримані в результаті кожного кроку декомпозиції, передаються на експертизу експертам предметної області. Експерти оцінюють відповідність реальних процесів створеним діаграмам. Знайдені невідповідності виправляються автором діаграми. Після проходження експертизи без зауважень виконується наступний сеанс декомпозиції.

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

Для створення діаграми дерева вузлів слід вибрати в меню пункт Add Node Tree. В результаті виникає діалогове вікно формування діаграми дерева вузлів Node Tree Wizard. У цьому вікні слід вказати кореневу роботу дерева і його глибину(кількість рівнів ієрархії).

Діаграма дерева вузлів показує ієрархію робіт у моделі і дозволяє розглянути всю модель цілком, але не показує взаємозв'язку між роботами (стрілки). Процес створення моделі робіт є ітераційним, отже, роботи можуть міняти своє розташування в дереві вузлів багаторазово. Щоб не заплутатися і перевірити спосіб декомпозиції, слід після кожної зміни створювати діаграму дерева вузлів. Втім, BPwin має могутній інструмент навігації по моделі - Model Explorer, який дозволяє представити ієрархію робіт і діаграм в зручному і компактному вигляді, проте цей інструмент є складовою стандарту IDEF0.

Рис. 3.13. Створення діаграми дерева вузлів

Діаграма дерева вузлів додається в модель для демонстрації взаємозв'язку всіх батьківських діаграм і діаграм-нащадків у вигляді ієрархії блоків в моделі, що дозволяє розглянути всю модель цілком. Діаграм дерев вузлів може бути в моделі як завгодно багато, оскільки дерево може бути побудоване на довільну глибину і не обов'язково з кореня. Ім'я дерева вузлів за замовчуванням збігається з ім'ям блоку верхнього рівня, а номер діаграми автоматично генерується як номер вузла верхнього рівня плюс буква «N», наприклад A0N. Якщо в моделі створюється два дерева вузлів, які мають в якості верхнього рівня одну і ту ж функцію, то за замовчуванням діаграми отримають ідентичні номер та ім'я. Тому рекомендується при створенні діаграми дерева вузлів задавати ім'я діаграми, відмінне від значення за замовчуванням.

Процес створення моделі функцій є ітераційним, отже, функції можуть міняти своє розташування в дереві вузлів багаторазово. Щоб не заплутатися і перевірити позиції, слід після кожної зміни створювати діаграму дерева вузлів. При створенні дерева вузлів обов'язково вказується ім'я діаграми, тому якщо в декількох діаграмах в якості кореня на дереві вузлів використовувати одну і ту ж функцію, то всі ці діаграми будуть мати однаковий номер (номер вузла + постфікс N, наприклад AON). У цьому випадку їх можна буде розрізнити по імені.

Вигляд діаграми дерева вузлів «Операції з нерухомістю» зображений на Рис. 3.14.

Рис. 3.14. Діаграма дерева вузлів

Створення звітів.

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

У BPwin вбудовані засоби для автоматичної генерації звітів. Звіти по моделі викликаються з пункту меню Report.

У BPwin існують такі типи звітів:

Model Report;

Diagram Report;

Diagram Object Report;

Activity Cost Report;

Arrow Report;

Data Usage Report;

Model Consistency Report;

Для побудови даної моделі вибираємо Model Report - звіт, який містить загальну інформацію про модель (її контекстній діаграмі) - ім'я моделі, точку зору, предметну область моделювання, мету, ім'я автора, дату створення та ін.

Рис. 3.15. Вибір типу звіту

Рис. 3.16. Налаштування даних для виводу звіту



Рис. 3.17. Вивід звіту

Висновок

Клас програмованих засобів (часто інтегрованих із CASE - системами) складають програмні системи мов програмування четвертого покоління (4GL). Такі мови являють користувачу більш зручні засоби для формування інтерфейса із кінцевим користувачем (наприклад, у вигляді меню чи форм), забезпечують порівняно прості можливості для взаємодії із системою управління базами даних, а також являють собою (звичайно, досить примітивні) засоби програмування. Основною перевагою мов четвертого покоління є те, що вони забезпечують можливість так званого "швидкого прототипування додатків (rapid prototyping)".

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

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

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

Зазначимо, що останнім часом подавляюча більшість CASE - систем та 4GL, якщо не орієнтуються, то звертають увагу на об'єктно-орієнтований підхід. Більш того, почали з'являтися методики по об'єктно-орієнтованому використанню засобів автоматизованого проектування та розробці інформаційних систем, які (засоби) початково для цього не призначалися. На сьогодні розробнику інформаційної системи, як мінімум, потрібно мати базові знання о сучасних СУБД, що орієнтуються у світі інструментальних засобів розробці програмних систем та мати уявлення про об'єктно-орієнтований підхід до проектування розробці програм.

Размещено на Allbest.ru