З курсу CASE- технології Усіх форм навчання

МІНІСТЕРСТВО ОСВІТИ І НАУКИ УКРАЇНИ

ХАРКІВСЬКИЙ НАЦІОНАЛЬНИЙ ЕКОНОМІЧНИЙ УНІВЕРСИТЕТ

Лабораторний практикум

з курсу «CASE- технології»

Для студентів спец. 7.080401, 7.080407

Усіх форм навчання

Укладачі: Мінухін С. В.

Беседовський О. М.

 

Відповідальний за випуск Пономаренко В. С.

Харків, ХНЕУ, 2005

Затверджено на засіданні кафедри інформаційних систем.

Протокол № 8 від 28.01.2005 р.

Лабораторний практикум з курсу «CASE-технології» для студентів спец. 7.080401, 7.080407 усіх форм навчання/ Укл. С. В. Мінухін, О. М. Беседовський– Харків: Вид. ХНЕУ, 2005. – с. (Укр. мов.)

 

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

Рекомендовано для студентів, які навчаються на спеціальностях комп’ютерного напрямку.

 

ВСТУП

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

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

Лабораторний практикум відбиває можливості використання інструментарію пакету BPwin щодо виконання лабораторних робіт за наступними темами:

Використання діаграм стандарту IDEF0 для опису бізнес-процесів – розглянуті базові принципи стандарту IDEF0, наведено приклади побудови моделі для опису предметної області з його застосуванням.

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

Побудова діаграм «як має бути» (TO-BE) – описані принципи переходу від моделі «як є» до моделі «як має бути».

Використання функціонально-вартісного аналізу для оцінки ефективності бізнес-процесів – розглянуто методику виокремлення центрів витрат та проведення функціонально-вартісного аналізу для визначення вартості бізнес-процесів.

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

Створення організаційних діаграм, діаграм Node Tree і Swim Lane – побудова спеціалізованих діаграм, що відбивають організаційну структуру підприємства; проектування робіт, котрі описують логіку взаємодії в стандарті IDEF3, на організаційну структуру; відображення сукупності взаємопов’язаних робіт у вигляді дерева вузлів.

Використання діаграм потоків даних (DFD) для опису предметної області – розглянуті принципи використання стандарту DFD для побудови моделей у заданій предметній області.

Експорт даних з BPwin у ERwin – розглянуто можливість експорту сутностей та атрибутів, котрі створюються в словниках BPwin та використовуються для опису сховищ даних в пакеті ERwin.

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

Лабораторна робота № 1

"Використання діаграм стандарту IDEF0 для опису бізнес-процесу"

 

Мета: ознайомлення з принципами проектування на основі CASE-технології; отримання практичних навичок щодо побудови моделі з використанням стандарту IDEF0 в BPwin.

Базові поняття

Об’єкт моделі – об’єкт в базі даних інструментального середовища моделювання, котрий володіє рядом атрибутів, і призначений для відображення реально… Бізнес-процес – цілеспрямована послідовність процедур, котра необхідна для… Процедура – впорядкована послідовність операцій, яка спрямована на отримання проміжного результату.

ТЕОРЕТИЧНА ЧАСТИНА

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

Основні елементи управління основної палітри BPwin

Основною моделлю опису процесів бізнесу в BPwin є модель IDEF0. Принципи побудови моделі на основі стандарту IDEF0 приведені далі.  

Принципи побудови моделі IDEF0 у BPwin

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

Приклад використання стандарту IDEF0 для побудови моделі, що описує процес управління договорами

 

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

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

Хід виконання лабораторної роботи.

Для початку роботи з BPwin необхідно зайти в пункт меню Пуск та зі списку програм вибрати Computer Associates BPwin 4.0 / BPwin 4.0(рис. 2).

 

Рис. 2. Завантаження BPwin 4.0

Далі, у відповідності з попередніми настройками, Вам буде потрібно або вибрати пункт меню File / New, або вікно створення/відкриття моделі буде автоматично відкрито при завантаженні BPwin (рис. 3).

 

Рис. 3. Вікно створення / відкриття моделі

В цьому вікні можна вибрати наступні дії:

– Create model – створення нової моделі; при цьому необхідно обов’язково вказати ім’я моделі (Name) та вибрати один з можливих стандартів – IDEF0, IDEF3, DFD;

– Open model – відкрити існуючу модель;

– Display this dialog on startup – починати роботу BPwin з цього вікна.

Нам необхідно створити нову модель з назвою „Управління договорами” в стандарті IDEF0.

Після натискання кнопки ОК Вам буде запропоновано внести властивості для створеної моделі, а саме: Author– внести прізвище та ініціали автора моделі (розробника) – внесіть у це поле свої дані. Після цього натисніть на кнопку ОК.

При цьому буде автоматично створена контекстна діаграма з єдиною роботою, що зображає систему в цілому. Контекстна діаграма представлена процесом (роботою) верхнього рівня. Робота зображується у вигляді прямокутника (рис. 4).

Примітка: При побудові моделей дуже частим явищем є незрозуміле зображення даних, які введені кирилицею (російською, українською та іншими мовами). Для їх адекватного сприйняття необхідно зробити наступне: зайти в пункт меню Model / Default Fonts та зробити наступні настройки як мінімум в пунктах Frame User Text та Frame System Text: змінити шрифт у полі Font на Times New Roman. Після цього треба зайти в пункт меню View / Redraw Diagramабо натиснути F12.

 

Рис. 4. Автоматично створена контекстна діаграма

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

При створенні і опису робіт слід зазначити, що вони повинні бути названі і визначені. Ім'я роботи повинно бути виражено віддієслівним іменником, що позначає дію (наприклад, "Планування постачань", "Моніторинг стану договорів" і т.д.). В нашому випадку процес буде мати ту ж саму назву, що і модель, тобто „Управління договорами”. Для внесення цієї назви необхідно двічі кликнути по лівій кнопці миші або один раз кликнути по правій кнопці та в контекстному меню, що з’явилося, вибрати пункт Name. При цьому відкривається діалог Activity Properties. Замість ім’я „Untitled Object 0” необхідно внести нове ім’я, наприклад, „Управління договорами на виробництво та постачання готової продукції”.

 

Рис. 5. Внесення назви бізнес-процесу

Основним роботам бізнес-процесу потрібно дати визначення – коротку характеристику. Так робота "Управління договорами на виробництво та постачання готової продукції" може мати наступне визначення: "Робота відноситься до повного циклу проходження договору на підприємстві від отримання заявки на товари підприємства та підписання договору до контролю його виконання та оплати". Для того, щоб її внести, необхідно перейти на закладку Definitionдіалогу Activity Properties та у відповідне поле внести вищезазначене визначення (рис. 6).

На закладці Status діалогу Activity Properties можна описати статус моделі: Working – робочий варіант, Draft – чорновий, Recommended – для редагування експертами, Publication – кінцевий варіант.

На вкладці Font цього ж діалогу треба обов’язково змінити параметри Font – на Times New Roman Cyr або Arial Cyr, можна змінити стиль тексту (жирний, курсив), кегель шрифту. Після того, як був змінений шрифт необхідно зробити наступні дії: відмітити пункти цієї закладки All activities in this diagram, All activities in this model, Change all occurrences of font in model. Це необхідно проробити, щоб для наступних робіт, інтерфейсних дуг та інших елементів моделі текст, котрий виводиться кирилицею зображувався зрозуміло користувачеві (рис. 7).

 

Рис. 6. Внесення визначення роботи

 

Рис. 7. Зміна параметрів шрифту для робіт

На вкладці Color можна змінити колір об’єктів для їх більш наочного зображення.

Для кожної моделі, як зазначалося вище, необхідно внести ціль та точку зору. Для того, щоб їх внести необхідно на робочій області моделі (будь-яка частина моделі, на якій немає об’єктів) натиснути на праву кнопку миші та з контекстного меню обрати пункт Model Properties, або обрати пункт меню Model / Model Properties. На вкладці Purposeнеобхідно внести ціль (Purpose) та точку зору (Viewpoint). Після цього треба натиснути на кнопку ОК (рис. 8).

Для створення і опису об'єктів на діаграмах використовуються інструменти BPwin Toolbox, які відмінні для різних моделей і стандартів (рис. 9).

У табл. 2 приведений опис призначення інструментів моделі IDEF0.

 

Рис. 8. Внесення мети і точки зору на модель що проектується

 

IDEF0	IDEF3	DFD

Рис. 9. Інструментарій BPwin Toolbox

 

Після того, як блок бізнес-процесу описаний, можна перейти до малювання інтерфейсних дуг. Для цього обираємо інструмент Precedence Arrow Tool. Для того щоб намалювати інтерфейсну дугу „вхід” підводимо інструмент до лівої межі діаграми і коли з’явиться чорна бордюрна лінія, натискаємо один раз на ліву кнопку миші. Підводимо інструмент до лівої грані блока процесу до моменту, коли з’явиться чорний трикутник (рис. 10) та знову один раз натискаємо на ліву кнопку миші.

 

Таблиця 2

Опис призначення інструментів моделі IDEF0

Аналогічним чином малюються інтерфейсні дуги управління (рис. 11) та механізму (рис. 12).    

Та кількості робіт на ній

Рис. 17. Автоматична декомпозиція контекстної діаграми  

Приклад опису задачі, що моделювалася

- вхід: замовлення, заявки; банківська виписка. - вихід: платіжна вимога; реєстр договорів; інформація про виконання… - управління: нормативно-правові акти договірних відносин; методика бухгалтерського обліку; методика управлінського…

Завдання на лабораторну роботу

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

У роботі проводиться побудова моделі “Управління договорами на виробництво та постачання готової продукції”.

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

Подальша робота проводиться студентом відповідно до виданого студенту варіанту з дод. А.

На основі побудованої моделі, необхідно оформити звіт по лабораторній роботі, що включає:

1) вхідні дані виконання роботи (запропонований варіант);

2) контекстну діаграму і всі діаграми декомпозиції відповідного варіанту, представлені в стандарті IDEF0;

3) опис процесу побудови діаграми у відповідності з наведеним у лабораторній роботі прикладом.

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. Що зображує діаграма IDEF0?

2. Перерахуйте основні елементи діаграми IDEF0.

3. Що входить в побудову контекстної діаграми?

4. Що таке бізнес-процес?

5. Що таке процедура?

6. Що таке бізнес-операція?

7. Назвіть базові принципи структурного підходу.

8. Які правила SADT використовуються для побудови моделей в стандарті IDEF0?

9. Які види інтерфейсних дуг використовуються в стандарті IDEF0? Дайте їм характеристику.

Лабораторна робота № 2

«Створення звітів вбудованими засобами BPwin»

 

Мета: вивчити типи звітів та способи їх створення; освоїти метод пошуку помилок в діаграмах, використовуючи звіти.

ТЕОРЕТИЧНА ЧАСТИНА

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

Приклад побудови звітів на основі вбудованих шаблонів

Звіт Model Consistency Report.

Для виклику звіту Model Consistency Report необхідно зайти в пункт меню Tools / Reports / Model Consistency Report. Звіт Model Consistency Report (або звіт про узгодженість з методологією) не має параметрів.

Зразок звіту Model Consistency Report приведений на рис. 35.

 

Рис. 35. Звіт Model Consistency Report

 

Звіт Diagram Object Report.

Список Standart Reports, що розкривається, дозволяє вибрати один із стандартних звітів. Стандартний звіт – це комбінація перемикачів, прапорців і…  

Звіт Model Report.

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

Model Name – назва моделі.

Definition – мета бізнес-процесів моделі.

Scope – предметна область моделі.

View point – точка зору на модель.

Time frame – тимчасові рамки моделі.

Status – міра готовності моделі.

Purpose – ціль створення моделі.

Source – джерело, на підставі якого створюється модель.

Author name – автор моделі.

Creation date – дата створення.

System last revision date – дата останнього перегляду в системі.

User last revision date – дата останнього перегляду користувачем.

 

Звіт Diagram Report.

• Для діаграм IDEF0 параметри задаються в рамках Activity options і Link options. Параметри в інших рамках не мають сенсу. Наприклад, група… • Для діаграм IDEF3 параметри задаються в рамках Activity Options, Link… • Для DFD-діаграм – в рамках Activity Options, Link Options, Data store Options і External Options.

Звіт Arrow Report.

Склад і функції цього вікна аналогічні решті звітів. В рамках Arrow Report Dictionary (Основні властивості стрілок), Source/Dest (Початок і кінець стрілок), Arrow Bundle (Розгалуження і злиття стрілок) розташовані опції, кожна з яких відповідає одній з властивостей стрілок. Установка такої опції поміщає відповідну властивість стрілки в звіт.

Опція Diagram Arrow визначає склад звіту. Якщо встановити цю опцію, то в звіт будуть включені стрілки активної діаграми. Якщо скинути – то в звіт включаються всі стрілки на всіх діаграмах відкритої моделі.

При формуванні звіту можна скористатися збереженими раніше настройками.

Створення звітів за допомогою Report Builder

Report Builder є простим генератором звітів, який входить до складу BPwin. Викликається цей інструмент за допомогою кнопки на панелі інструментів… Пункт меню Tools/Reports Builder викликає діалог Report Templates (рис. 38),…  

Кнопки панелі інструментів діалогу Report Template Builder

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

Завдання на лабораторну роботу

Робота виконується на основі моделі, котра побудована в лабораторній роботі № 1.

Необхідно оформити звіт по лабораторній роботі, що включає:

1) звіт по моделі;

2) стандартний звіт по стрілках;

3) звіт по об’єктах діаграми;

4) звіт про узгодженість з методологією;

5) звіт, побудований за допомогою генератора звітів.

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. Назвіть типи звітів в BPwin.

2. В чому сутність звіту про узгодженість з методологією?

3. В які формати можна експортувати звіти?

4. Які типи помилок виокремлюються в BPwin, які з них відображаються в Model Consistency Report?

5. Що означають опції Current і Specify at Run Time в розділі Туре секції Picture генератора звітів.

 

Лабораторна робота № 3

"Побудова діаграм як має бути (TO-BE)"

 

Мета: на основі аналізу предметної області та недоліків існуючого функціонування процесу, побудувати діаграми TO-BE в стандарті IDEF0.

ТЕОРЕТИЧНА ЧАСТИНА|

 

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

Метою побудови функціональних моделей звичайно є виявлення найбільш слабких і вразливих місць діяльності організації, аналіз переваг нових процесів бізнесу і міри зміни існуючої структури організації бізнесу. Аналіз недоліків і "вузьких місць" починають з побудови моделі АS-IS (як є), тобто моделі існуючої організації роботи. Модель АS-IS може будуватися на основі вивчення документації (посадових інструкцій, положень про підприємство, наказів, звітів і т. ін.), анкетування і опитування службовців підприємства, створення фотографії робочого дня і інших джерел. Одержана модель АS-IS служить для виявлення дубльованих робіт, робіт не забезпечених ресурсами, неефективних робіт і інших недоліків в організації діяльності підприємства. Виправлення недоліків, перенаправлення інформаційних і матеріальних потоків призводить до створення моделі ТО-ВЕ (як повинно бути) – моделі близької до ідеальної організації процесів бізнесу.

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

Для забезпечення процедури прийняття рішення будується декілька, моделей ТО-ВЕ, серед яких визначають найкращий варіант. Вибір оптимальної моделі може здійснюватися згідно критеріям часу, величині витрат процесів, котрі описуються, вартості робіт по переведенню об'єкту із стану АS-IS в ТО-ВЕ.

Технологія проектування інформаційних систем має на увазі:

1) створення моделі АS-IS;

2) аналіз і покращання існуючих процесів бізнесу – створення моделі ТО-ВЕ;

3) побудова на основі моделі ТО-ВЕ моделі даних – прототипу і остаточного варіанту інформаційної системи.

Приклад використання стандарту IDEF0 для побудови моделі TO-BE, що описує процес управління договорами

Розробник моделі перед тим, щоб перейти до побудови моделі «як повинно бути», має визначити ті роботи, котрі можуть бути: – видалені у зв’язку з їх незначущістю або по іншим причинам; – об’єднані у зв’язку з тим, що роботи є продовженням одна одної з одним й тим же виконавцем, а формування звіту по…

Приклад опису задачі, що моделювалася

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

Завдання на лабораторну роботу

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

У роботі проводиться побудова моделі “Управління договорами” типу «як має бути» на основі завдання лабораторної роботи № 1.

На основі побудованої моделі, необхідно оформити звіт по лабораторній роботі, що включає:

1) контекстну діаграму і всі діаграми декомпозиції відповідного варіанту, представлені в стандарті IDEF0;

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

3) звіт, розроблений на основі вбудованих шаблонів та/або генератора звітів (обов’язкова включити звіт про узгодженість з методологією).

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. В чому сутність моделі ТО-ВЕ та її відмінність від моделі AS-IS?

2. Які основні шляхи реорганізації бізнес-процесів?

3. Як і де в BPwin можна вказати тип моделі ТО-ВЕ?

4. В чому складається сутність технології проектування ІС?

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

Лабораторна робота № 4

"Використання функціонально-вартісного аналізу для оцінки ефективності бізнес-процесів"

 

Мета: навчитися проводити аналіз моделі з використання функціонально-вартісного аналізу.

 

Базові поняття

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

Об'єкт витрат– процес, котрий досліджується, структуру формування процесів на основі використання функціонального підходу; робота, на яку провадяться витрати;

Властивості витрат– характеристики входів і управління роботи, які впливають на час її виконання (наприклад, частота робіт, тривалість);

Центри витрат, які можна трактувати як статті витрати по об'єкту управління (дослідження) (об’єктах витрат).

 

ТЕОРЕТИЧНА ЧАСТИНА

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

Взаємозв'язок елементів витрат і статей калькуляції

1) функціонально-вартісний аналіз, заснований на описі існуючих робіт проекту; 2) використання характеристик і властивостей, котрі визначаються користувачем… ФВА-аналіз є широко поширеною методикою, яка використовується міжнародними корпораціями і державними організаціями для…

Приклад використання ФВА для аналізу моделі

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

Розрахунок витрат за статтями витрат для проведення функціонально-вартісного аналізу

*** цехові витрати приймаються у розмірі 200% від фонду основної і додаткової заробітної плати; **** загальногосподарські витрати приймаються у розмірі 100% від фонду…  

Завдання на лабораторну роботу

Треба провести функціонально-вартісний аналіз для моделей „як є”, побудованої у лабораторній роботі № 1, та „як має бути”, побудованої у лабораторній роботі № 3.

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

1) контекстну діаграму і всі діаграми декомпозиції моделі „як є” з результатами ФВА;

2) контекстну діаграму і всі діаграми декомпозиції моделі „як має бути” з результатами ФВА;

3) таблиці розрахунку показників для ФВА;

4) провести аналіз та описати відмінності проаналізованих моделей „як є” та „як має бути” за результатами ФВА;

5) звіт, розроблений на основі вбудованих шаблонів (звіт Activity Cost Report) та генератора звітів з секцією Cost Center.

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. В чому сутність функціонально-вартісного аналізу?

2. Дайте визначення об’єкту витрат. Наведіть приклад.

3. Дайте визначення властивості витрат. Наведіть приклад.

4. Дайте визначення центру витрат. Наведіть приклад.

5. Перерахуйте статті витрат.

6. Які два інструменти BPwin можна використовувати для оцінки моделі?

Лабораторна робота № 5

"Використання діаграм, що описують логіку взаємодії робіт для опису предметної області з застосуванням стандарту IDEF3"

 

Мета: описати взаємозв'язок між роботами та побудувати діаграми IDEF3 для опису предметної області.

Базові поняття

Зв'язок– елемент (стрілка), що характеризує взаємостосунки робіт. Робота-мета– робота, яка запускається після роботи-джерела. Перехрестя– елемент діаграми, що відображає логіку взаємодії стрілок, при злитті і розгалуженні.

Опис призначення інструментів моделі IDEF3

Основними компонентами моделі IDEF3 є: зв'язки і перехрестя. Зв'язки.Зв'язки показують взаємодію робіт. Всі зв'язки в IDEF3 спрямовані в… Старша стрілка – суцільна лінія, що зв'язує одиниці робіт. Малюється зліва направо або зверху вниз. Показує, що…

Типи перехресть

1. Кожному перехрестю для злиття повинне передувати перехрестя для розгалуження. 2. Перехрестя для злиття "І" не може слідувати за перехрестям для… 3. Перехрестя для злиття типу виключаючого "АБО" не може слідувати за перехрестям для розгалуження типу…

Приклад використання стандарту IDEF3 для побудови моделі, що описує процес управління договорами

Рис. 61. Виправлений вигляд діаграми Тому після побудови контекстної діаграми і діаграми її декомпозиції (рис. 45 – 46) в стандарті IDEF0 (не доцільно…

Завдання на лабораторну роботу

 

Студент повинен проаналізувати модель „як повинно бути”, побудовану у лабораторній роботі № 3 та вирішити, які діаграми є сенс зробити в стандарті IDEF3.

На основі побудованої моделі, необхідно оформити звіт по лабораторній роботі, що включає:

1) вхідні дані виконання роботи (запропонований варіант);

2) контекстну діаграму і діаграму декомпозиції до рівня етапів, представлені в стандарті IDEF0;

3) діаграми декомпозиції вузлів відповідного варіанту, представлені в стандарті IDEF3;

4) звіт, що включає дані про модель, автора, мету побудови моделі, точці зору, роботах. Звіт може бути виконаний або за допомогою вбудованих шаблонів звітів, або за допомогою генератора звітів Report Builder.

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. Що зображує діаграма IDEF3?

2. Перерахуйте основні елементи діаграми IDEF3.

3. Що характеризують зв’язки в діаграмах IDEF3?

4. Перерахуйте типи стрілок в діаграмах IDEF3.

5. Що називається перехрестям?

6. Назвіть типи перехресть?

7. Назвіть правила для побудови перехресть.

8. Що таке об’єкт посилань?

 

Лабораторна робота № 6

"Створення організаційних діаграм, діаграм Node Tree і Swim Lane"

 

Мета: навчитися створювати спеціалізовані діаграми дерева вузлів, організаційну та Swim Lane.

Базові поняття

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

Організаційна діаграма – діаграма, що дозволяє документувати і представити у вигляді дерева структуру організації.

 

ТЕОРЕТИЧНА ЧАСТИНА

 

У BPwin існує п'ять видів спеціалізованих діаграм, до числа яких входять Node Tree, Swim Lane і діаграми Organization Charts.

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

 

Хід виконання лабораторної роботи

 

Для того, щоб побудувати спеціалізовану діаграму дерева вузлів, необхідно перейти на закладку Diagrams у вікні Model Explorer і вибрати Node Tree diagrams або вибрати пункт меню Diagram / Add Node Tree.. При цьому на екрані з'явиться гід Node Tree Wizard (рис. 64). У цьому вікні повинні бути задані назва діаграми дерева вузлів, верхній її рівень (найчастіше контекстна діаграма) і кількість рівнів декомпозиції, які відображатимуться на цій діаграмі.

 

Рис. 64. Вікно гіда діаграми дерева вузлів

 

У наступному діалоговому вікні гіда необхідно вказати настройки для діаграми дерева вузлів (рис. 65).

 

Рис. 65. Настройки для діаграми дерева вузлів

 

У числі цих настройок відзначимо:

Drawing:

Bullet last level – останній рівень декомпозиції подати у вигляді маркірованого списку;

Show node numbers – вказати номери вузлів;

Show boxes – показати межі для блоків;

Border:

Include Kit – включити в діаграму шапку моделі;

Include title – включити в діаграму підвал моделі;

Box size:

Fit each box to text – розміри блоків залежать від тексту в них;

One size per row – встановлюється один і той же розмір блоків для одного рівня декомпозиції;

All one size – розмір всіх блоків однаковий.

Зробіть настройки так, як показано на рис. 65.

Після клацання на кнопці Готово створюється діаграма дерева вузлів (рис. 66).

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

Словник Role Group Dictionary (меню Dictionary/Role Group, рис. 67) дозволяє створити і визначити властивості груп ролей. Групи ролей можуть використовуватися як на організаційних діаграмах, так і на діаграмах Swim Lane. Як значення групи ролей можуть бути назви підприємства, відділу, цеху або назви регіону, міста і т.д.

 

Рис. 67. Словник групи ролей

а) без настройки „Bullet last level”

б) з настройкою „Bullet last level”

 

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

Для кожної групи ролей повинно бути внесено найменування (Name), може бути внесено опис (Definition), вказано зображення (Bitmap), заздалегідь імпортоване в словник зображень і вказана важливість групи ролей (Importance).

Наступний словник, який треба заповнити – словник ролей. Він викликається з меню Dictionary/Role (рис. 68).

 

Рис. 68. Словник ролей

 

Роллю може бути посада або позиція конкретного виконавця. Кожній ролі може відповідати одна або декілька груп ролей. Крім того, в словнику ролей для кожної ролі необхідно внести найменування (Name), можна внести визначення (Definition), віднести цю роль до певної групи ролей (Role Group), вказати зображення (Bitmap), геометричну фігуру, яка відповідатиме цій групі ролей (Shape), вказати важливість ролі (Importance).

Словник ресурсів (меню Dictionary/Resource, рис. 69) дозволяє створити ресурс і пов'язати його з комбінацією «група ролей / роль». Ресурсом для ролі може бути конкретний виконавець. Як значення ресурсу, наприклад, можна використовувати прізвище і ім'я працівника.

На основі інформації, внесеної в словники груп ролей, ролей і ресурсів, можна створити організаційну діаграму. Організаційна діаграма дозволяє документувати і представити у вигляді дерева структуру організації (наприклад, штатний розклад і т.д.). Для її створення необхідно перейти на закладку Diagrams у вікні Model Explorer і вибрати Organization Charts або вибрати пункт меню Diagram / Add Organization Chart. При цьому на екрані з'явиться гід Organization Chart Wizard (рис. 70). У першому діалозі гіда слід внести найменування (Name) і ім'я автора діаграми (Author), групу ролей (Role Group), роль (Role) і ресурс (Resource) для верхнього рівня ієрархічного дерева.

 

Рис. 69. Словник ресурсів

 

Рис. 70. Перше вікно діалогу гіда Organization Chart Wizard

 

Друге вікно діалогу гіда (рис. 71) дозволяє створити другий рівень ієрархічного дерева. Верхній список містить всі доступні ролі з асоційованими ресурсами, нижній – ролі і ресурси другого рівня ієрархії. Кнопка Add дозволяє перенести ролі і ресурси з верхнього списку в нижній, а кнопка Remove – навпаки.

 

Рис. 71. Створення другого рівня організаційної діаграми

 

Третє вікно діалогу Organization Chart Wizard (рис. 72) призначене для зміни властивостей організаційної діаграми. Крім властивостей, котрі вже були описані для рис. 65, у групі Drawing, також, можна вказати, яка саме інформація відображатиметься на блоках діаграми (найменування групи ролей, ролі і ресурсу).

Після натиснення на кнопці Готово створюється організаційна діаграма (рис. 73).

Для доповнення діаграми слід клацнути правою кнопкою миші по блоку і вибрати в контекстному меню (рис. 74) один з пунктів:

Edit subordinate list – редагування блоку;

Add subordinates – додавання нижнього рівня;

Add sibling on left – додавання блоку на поточний рівень зліва від редагованого блоку;

Add sibling on right – додавання блоку на поточний рівень праворуч від редагованого блоку;

Delete box and subtree – видаляє виділений блок і все дерево організаційної діаграми нижче за нього.

 

Рис. 72. Діалог зміни властивостей організаційної діаграми

 

Рис. 73. Перший, другий і третій рівень організаційної діаграми

 

Рис. 74. Контекстне меню редагування організаційної діаграми

Нам треба додати додаткові блоки на нижньому рівні (Add subordinates), та внести для них ролі та ресурси (двічі лівою кнопкою миші на відповідному блокові). Після цього отримаємо організаційну діаграму, котра зображена на рис. 75.

 

Рис. 75. Доповнена організаційна діаграма

 

Створені в словнику Role Dictionary ролі можуть бути також використані в діаграмі Swim Lane. Діаграма Swim Lane є різновидом діаграми IDEF3, що дозволяє явно описати ролі і відповідальності виконавців в конкретній технологічній операції. Ця діаграма розділена на горизонтальні смуги, з кожною смугою може бути пов'язана роль або UDP типу Text List. Смуга може містити об'єкти діаграми IDEF3 (UOW, перехрестя і об'єкти посилань), що відносяться до відповідної ролі.

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

Для створення діаграми Swim Lane необхідно перейти на закладку Diagrams у вікні Model Explorer і вибрати Swim Lane diagrams або вибрати пункт меню Diagram / Add Swim Lane diagram.. При цьому на екрані з'явиться гід Swim Lane Diagram Wizard. У першому діалозі гіда (рис. 76) слід вибрати групу ролей, з якої можна буде вибрати ролі, пов'язані з діаграмою, вибрати ім'я і номер діаграми IDEF3, на основі якої буде побудована діаграма і внести назву діаграми.

 

Рис. 76. Перший діалог гіда Swim Lane Diagram Wizard

 

У другому діалозі гіда (рис. 77) слід вибрати ролі, на основі яких буде створена діаграма. Діаграма буде розділена на кількість смуг, вказаних в колонці Display Swim Lane. Після натиснення на кнопці Готово створюється нова діаграма, всі об'єкти якої розташовані довільно. Розташувати об'єкти на смугах, відповідних ролям, має зробити вручну (рис. 78).

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

 

 

Рис. 77. Вибір ролей в другому діалозі гіда Swim Lane Diagram Wizard

 

Рис. 78. Діаграма Swim Lane

Завдання на лабораторну роботу

 

На основі побудованих діаграм, необхідно оформити звіт по лабораторній роботі, що включає:

1) діаграму дерева вузлів для моделі „як має бути”;

2) організаційну діаграму;

3) діаграми Swim Lane.

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. Для чого використовується діаграма дерева вузлів?

2. Сутність організаційної діаграми.

3. Що таке група ролей?

4. Дайте характеристику ролі.

5. Що таке ресурси?

6. Сутність діаграми Swim Lane.

 

 

Лабораторна робота № 7

"Використання діаграм потоків даних (DFD) для опису предметної області"

 

Мета: описати потоки даних і інформаційні потоки за допомогою діаграм DFD в BPwin.

Базові поняття

Зовнішнє посилання– джерело або приймач даних ззовні моделі; представляють входи в систему і/або виходи з системи.

Сховище даних– описує дані, які необхідно зберегти в пам'яті перш, ніж використовувати в роботах.

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

Процес – складається в продукуванні вихідних потоків із вхідних відповідно до дії, що задає ім'я процесу.

 

ТЕОРЕТИЧНА ЧАСТИНА

Діаграми потоків даних (Data flow diagramming, DFD) використовуються для опису документообігу і обробки інформації. Подібно IDEF0, DFD представляє… функції обробки інформації (роботи); документи (стрілки, arrows), об'єкти, співробітників або відділи, які беруть участь в обробці інформації;

Хід виконання лабораторної роботи

Діаграми будуються аналогічно вищезазначеним роботам. В нашому прикладі ми збудуємо модель „як має бути” в стандарті DFD.

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

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

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

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

заявки, замовлення (на виготовлення продукції) від Клієнта до Підприємства.

платіжні вимоги – (дані про відвантажену продукцію покупцям) від Підприємства до Клієнта.

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

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

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

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

Після цього необхідно зайти в пункт меню Dictionary / Entity і внести в Entity Dictionary всі сутності, яка використовуватиметься для сховищ даних (рис. 83).

Наступний крок проектувальника – внесення для кожної з сутностей набору атрибутів. Для цього необхідно зайти в пункт Dictionary / Attribute (рис. 84).

 

 

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

Рис. 82. Діаграма декомпозиції контекстної діаграми в стандарті DFD

Рис. 83. Словник сутностей

 

Рис. 84. Словник атрибутів

 

Тільки після вищезазначених дій можна вносити сховища даних у діаграму. При створенні сховища даних необхідно натиснути на кнопку . на панелі інструментів, а потім на чистому полі робочої області. З'явиться вікно введення даних про сховище даних (рис. 85). Необхідно вибрати радіокнопку Entity і в зміненому вікні (рис. 86) вибрати найменування сутності з спадаючого списку, які були внесені в словник сутностей заздалегідь. Після цього натиснути на кнопку ОК.

 

Рис. 85. Вікно створення сховища даних

Рис. 86. Вікно вибору сутності з словника сутностей

 

Таким чином створюються всі сховища даних.

До них відносяться наступні:

довідник цін на продукцію – призначений для зберігання даних по всіх цінах на продукцію;

довідник клієнтів – призначений для зберігання даних по всіх клієнтах;

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

виробничий календар – призначений для зберігання даних виробничого календарю;

довідник стану договору – призначений для зберігання даних по всіх станах договору;

довідник регіонів – призначений для зберігання даних по всіх регіонах, у відповідності до адміністративно - територіального ділення України;

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

Специфікації роботи "Ведення реєстру договорів" наведені нижче.

ВХІД: замовлення, заявки; інформація про виконання договірних обов’язків.

ВИХІД: інформація договорів та реєстр договорів.

АЛГОРИТМ: прийняти від клієнтів заяви на виготовлення продукції та інформацію про виконання договірних обов’язків від менеджеру відділу збуту; оформити та виконати договір; провести контроль виконання договорів; вибрати із відповідних довідників інформацію, необхідну для складання вихідних документів.

Специфікації роботи "Планування постачань" наведені нижче.

ВХІД: інформація договорів; інформація накладних на відвантаження продукції.

ВИХІД: інформація плану поставок; інформація портфелю замовлень; інформація про платіжну вимогу.

АЛГОРИТМ: прийняти вхідні документи; вибрати із відповідних довідників інформацію, необхідну для складання вихідних документів; передати; передати платіжну вимогу клієнту.

Специфікації роботи "Планування випуску та облік ГП" наведені нижче.

ВХІД: інформація договорів; інформація плану поставок; інформація портфелю замовлень; накладна на передачу готової продукції до складу.

ВИХІД: інформація графіку відвантаження; інформація накладних на відвантаження продукції.

АЛГОРИТМ: прийняти вхідні документи; вибрати із відповідних довідників інформацію, необхідну для складання вихідних документів; вихідний документ – інформація накладних на відвантаження продукції передати на попередню роботу менеджеру відділу збуту.

Специфікації роботи "Контроль та аналіз виконання договорів" наведені нижче.

ВХІД: інформація договорів; банківська виписка; інформація про платіжну вимогу; інформація накладних на відвантаження продукції; інформація графіку відвантаження.

ВИХІД: інформація про виконання договірних обов’язків.

АЛГОРИТМ: прийняти вхідні документи; вибрати із відповідних довідників інформацію, необхідну для складання вихідних документів; вихідний документ передати на до першої роботи та у відділ маркетингу.

На рис. 87 наведена діаграма потоків даних, що деталізує роботу "Ведения реєстру договорів" по допоміжних роботах, які виконуються при загальному вирішенні даної роботи. Функціонально робота розбивається на наступні допоміжні роботи: заключення договору, виконання договору та контроль за виконанням та включення до реєстру.

На рис. 88 наведена діаграма потоків даних, що деталізує роботу "Планування постачань" по допоміжних роботах, які виконуються при загальному вирішенні даної роботи. Функціонально робота розбивається на наступні допоміжні роботи: формування календарних планів поставок, формування платіжної вимоги та формування портфелю замовлень.

На рис. 89 наведена діаграма потоків даних, що деталізує роботу "Планування випуску та облік ГП" по допоміжних роботах, які виконуються при загальному вирішенні даної роботи. Функціонально робота розбивається на наступні допоміжні роботи: формування виробничої програми випуску продукції, складання графіку відвантаження продукції покупцям, облік випуску ГП та передача на склад, та складський облік ГП.

На рис. 90 наведена діаграма потоків даних, що деталізує роботу "Контроль та аналіз виконання договорів" по допоміжних роботах, які виконуються при загальному вирішенні даної роботи. Функціонально робота розбивається на наступні допоміжні роботи: контроль виконання графіку відвантаження, контроль оплати рахунків за поставлену продукцію, та аналіз виконання договірних зобов’язань.

 

Завдання на лабораторну роботу

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

На основі побудованої моделі, необхідно оформити звіт по лабораторній роботі, що включає:

1) вхідні дані виконання роботи (запропонований варіант);

2) контекстну діаграму та діаграми декомпозиції вузлів відповідного варіанту, представлені в стандарті DFD;

3) таблицю розрахунку витрат для функціонально-вартісного аналізу;

4) звіт, що включає дані про модель, автора, мету побудови моделі, точку зору, роботах і функціонально-вартісному аналізу. Звіт може бути виконаний або за допомогою вбудованих шаблонів звітів, або за допомогою генератора звітів Report Builder.

 

КОНТРОЛЬНІ ЗАПИТАННЯ

1. Що зображує діаграма DFD? 2. Яка нотація використовується в BPwin для побудови діаграм DFD? 3. Перерахуйте складові частини діаграми DFD.

Лабораторна робота № 8

"Експорт даних з BPwin у ERwin"

 

Мета: навчитися експортувати дані з BPwin у Erwin, і будувати логічну та фізичну моделі даних на їх основі.

Хід виконання лабораторної роботи

 

Для експорту одержаних сутностей і атрибутів в ERwin необхідно після створення всіх сутностей с атрибутами зайти в пункт меню File / Export / ERwin 4.0 (BPX) (рис. 91). При цьому на екрані з’явиться вікно, в котрому треба ввести ім’я файлу, в якому будуть збережені дані і вказати де буде знаходитися файл даних (рис. 92).

 

Рис. 91. Експорт сутностей і атрибутів з BPwin в ERwin

Рис. 92. Перший етап експорту даних

Після цього необхідно завантажити ERwin, створити нову модель (логічну та фізичну) (рис. 93). Для імпорту даних необхідно зайти в пункт File / Import / BPwin (рис. 94) та вибрати файл даних, з котрого буде проведений імпорт (рис. 95).

 

Рис. 93. Вікно створення нової моделі

 

Рис. 94. Вибір пункту меню імпорту даних з BPwin

 

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

 

Рис. 95. Вибір файлу для імпорту даних

 

Рис. 96. Вікно вибору сутностей та атрибутів для імпорту

 

Результатом імпорту буде вікно з сутностями, зображеними на рис. 97. Найчастіше імпортовані дані спочатку будуть мати незрозумілий вигляд. Для нормального їх відображення необхідно зайти в пункт меню Format / Default Fonts & Colors (рис. 98) та змінити для сутностей та атрибутів значення поле Font на Arial Cyr або Times New Roman Cyr, та в пункті Apply To вибрати радіокнопку All Objects (рис. 99).

 

Рис. 97. Вікно з імпортованими даними

 

Рис. 98. Меню вибору шрифту за замовчуванням

 

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

 

Завдання на лабораторну роботу

Експортувати дані з BPwin у ERwin та побудувати на їх основі логічну та фізичну моделі даних.

На основі побудованих моделей, необхідно оформити звіт по лабораторній роботі, що включає:

1) вхідні дані виконання роботи (запропонований варіант);

2) логічну і фізичну моделі даних, які розроблені на основі експорту сутностей і атрибутів з BPwin в ERwin;

 

Рис. 99. Вікно зміни шрифту для сутностей та атрибутів

 

КОНТРОЛЬНІ ЗАПИТАННЯ

 

1. Що зображує діаграма IDEF1x?

2. Що необхідно для експорту даних з BPwin у ERwin?

3. Що таке сутність?

4. Що таке атрибут?

 

РЕКОМЕНДОВАНА ЛІТЕРАТУРА

 

1. Маклаков С.В. Моделирование бизнес-процессов с BPwin 4.0. – М.: Диалог МИФИ, 2002. – 224 с.

2.Маклаков С.В. BPwin и ERwin. CASE-средства разработки информационных систем. – М.: Диалог МИФИ, 2000. – 256 с.

3. Маклаков С.В. Создание информационных систем з AllFusion Modeling Suite. - М.: Диалог-мифи, 2003. – 432 с.

4. Федотова Д.Э., Семенов Ю.Д., Чижик К.Н. CASE-технологии: Практикум. – М.: Горячая линия-Телеком, 2003. – 160 с.

Додаток А

  Задача 0601 «Ведення реєстру договорів на постачання (продаж) продукції… Необхідна функціональність:

Лабораторний практикум

з курсу «CASE-технології»

Для студентів спец. 7.080401, 7.080407

Усіх форм навчання

 

Укладачі Мінухін Сергій Володимирович

Беседовський Олексій Миколайович

 

Відповідальний за випуск Пономаренко В. С.

Редактор

Коректор

План 2005 р. Поз. №

Підп. до друку Формат 60х90 1/16. Папір MultiCopy. Друк RISO.

Ум.–друк. арк.___ Обл.-вид. арк. ___Тираж _100_ прим. Зам. № _____

 

 

_____________________________________________________________________________

Свідоцтво про внесення до Державного реєстру суб’єктів видавничої справи Дк №481 від 13.06.2001 р.

____________________________________________________________

Видавець і виготівник – видавництво ХНЕУ, 61001, м. Харків, пр. Леніна, 9а