Моделювання технічних систем c AllFusion Process Modeler (раніше BPwin), Комерція, Різне, статті

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

Одна з головних цілей моделювання – представити або в уяві, або у вигляді матеріальної (шаблон для копіювального верстата) або біологічної моделі (собака Павлова; білкова модель – геном людини), або в формалізованому вигляді на папері (креслення, технологічний процес, нотний лист, Правила дорожнього руху, текст на природній мові, і т.д.), або в електронному вигляді (файл AllFusion Process Modeler 4.1), об’єкт майбутньої нам діяльності. Така модель класифікується як TO BE – як має бути.

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

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

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

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

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

Весь навколишній світ структурується на чотири групи об’єктів, це:


Відповідно предметом моделювання можуть бути, незалежно, чи взаємозалежне:


Це узагальнення знайшло відображення в розробленій більше 40 років тому Дугласом Т. Россом (США) концепції функціонального блоку, оснащеного чотирма типами зв’язків – входом, управлінням, виходом і механізмом – Як основою функціональної моделі.

За характером складових їх об’єктів, системи, поділяються на три групи:


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

Таблиця 1. Методи моделювання матеріальних, інформаційних та енергетичних та організаційних систем






































Тип системи Об’єкти системи, що піддаються моделюванню
Пристрій системи Функції системи Об’єкти обміну в проц. функц. Управління системою
Входи системи Виходи системи
Матеріальна 1. Креслення, матеріальні моделі, або CAD / CAM інформація в цифровому електронному форматі 2. Структурні, потокові, імітаційні і вартісні функціональні моделі 3. Специфікації, що генеруються на основі інформації функціональної моделі системи, у тому числі – її інтерфейси. 4. Спеціалізована матеріально – інформаційна надбудова у відповідних формах матеріальної та інформаційної систем
Інформаційна 5. Фізична модель структури бази даних; креслення матеріальних фрагментів системи 6. Структурні, потокові, імітаційні, і вартісні функціональні моделі, в тому числі – алгоритми роботи інформаційних систем 7. . Специфікації, що генеруються на основі інформації функціональної моделі системи, у тому числі – її інтерфейси; діаграми сутність – зв’язок (ERD1) Моделі даних системи, форми введення – виведення даних. 8. Входи інформаційної системи, що характеризуються як масив можливих запитів до системи
Енергетична 9. Монтажні електричні схеми 10. Принципові електричні схеми 11. Фрагменти електросхем – див осередку 9, 10, в тому числі – інтерфейси енергосистеми 12. Фрагменти пристрої та функцій системи та її інтерфейси
Люди в системі 13. Схема організаційної структури 14. Фрагменти ФМ з осередків 2, 6 15. Інтерфейси2 матеріальної, інформаційної та енергоподсістем 16. Посадові обов’язки, що апелюють до інтерфейсів системи 17. Формування системи зв’язків підпорядкованості в межах оргструктури, забезпечення їх визнання і виконання.

Особливе, основне, положення в цьому переліку займає система, як носій функціонування, обмінів і об’єкт управління.

Повний опис системи може бути здійснено за наявності всіх перерахованих в табл. № 1 типів моделей, пов’язаних між собою. Проте, в силу різних приватних задач моделювання, має сенс і розробка окремих приватних моделей, або тієї чи іншої їх вибірки.

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

Як і механізми, входи можуть бути не вказані.

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

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

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

Всі системи моделювання крім згаданого режиму TO BE, працюють, також, в режимі AS IS. Модель AS IS – як правило інструмент аналізу роботи системи, модель TO BE – це завдання на наступне створення модельованої системи.

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

Основна задача розробки будь-якої моделі, кінцева чи проміжна мета її розробки, як AS IS, так і TO BE моделі – оцінка, з її допомогою, коректності та оптимальності модельованої системи.

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

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


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


Другий випадок відноситься до здійснення комп’ютерної підтримки розробки програмного забезпечення – CASE – технології.3

Особливе, кілька відсторонене, що має потужно розвинуту методичну базу, яка підтримується енергійно розвиваються, методично і програмно, CAD / CAM – системами місце займають системи моделювання4 пристрою матеріальних систем5 – Див осередок № 1 таблиці 1. За допомогою цих інструментів розробляють конструкторську документацію (в паперовому вигляді), або цифрову електронну конструкторську інформацію. В обох випадках забезпечується фізична виготовлення системи.

Більш-менш стійко і консервативно стан у сфері засобів моделювання енергетичних систем, відбите в осередках 9, 10, 11, 12. Моделі енергетичної підсистеми в більшості випадків – за винятком систем масштабу регіонального енергозабезпечення, є наслідком і деталізацією моделей, наведених в осередках 1, 2, 5.

Моделі, зазначені в осередках 1, 9, 10, 11, 12 не є предметом цього розгляду

Для моделей даних (див. осередок 7), що розробляються, як правило, в процесі здійснення CASE – технологій, досить стійко, у міжнародній і вітчизняній практиці, зарезервовано місце стандартизованої, на федеральному рівні в США, методики IDEF1X та її програмної реалізації AllFusion Erwin Data Modeler. Найбільша різноманітність представляють можливості для моделювання, представленого в осередках 2 і 6 – функціонального моделювання матеріальних та інформаційних систем. Ці моделі – функціональні моделі – є, як правило, основою аналізу функціонують і створення нових систем.

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

Одним з слабопроработанних до теперішнього часу питань, що викликають постійні труднощі, методично слабо підтриманих, є моделювання управління людьми в системі (осередок 17), інтегрованих в архітектурі тієї чи іншої організаційної структури. Це завдання може бути отмоделировать самостійно. Рідкісним прикладом розвиненою текстової моделі управління організаційною структурою може служити міжнародний стандарт ISO 9001:2000, що регламентує функціонування системи менеджменту якості6 .

Схема організаційної структури (див. осередок 13) є документом, призначеним для організації взаємодії людей, що беруть участь в роботі системи. Значною частиною роботи цих людей є саме відповідальне – УПРАВЛІННЯ роботою системи. Моделювання цієї взаємодії зводиться до формування схеми підлеглості одних працівників іншими, і грунтується, як мається на увазі, на визнання усіма учасниками відносин підлеглості, оголошених в цій схемі7.

Активну роботу в сфері створення комплексу засобів технічного моделювання веде американська компанія Computer Associates (Річний оборот – близько 6 мільярдів доларів), що знаходиться в числі найбільших розробників і постачальників програмних продуктів – на третьому місці після Microsoft і Oracle. В оголошених їм стратегічних цілях комплекс AllFusion Modeling Suite (Інтегрований пакет засобів моделювання) входить в Application Life Cycle Management (див. рис 2) – одне з шести напрямків розвитку, покликаних підтримувати розвиток електронного бізнесу (див. рис. 3).

AllFusion Modeling Suite дозволяє здійснити розробку тих моделей, які зазначені в таблиці 1 заливкою, складається з цілого ряду взаємопов’язаних програмних пакетів, що забезпечують як власне моделювання, так і підтримуючих ефективну, у тому числі колективну, роботу системних аналітиків, які беруть участь у розробці комплексу моделей:


  1. AllFusion Process Modeler,
  2. AllFusion Erwin Data Modeler,
  3. AllFusion Data Model Validator,
  4. AllFusion Model Manager,
  5. AllFusion Component Modeler,
  6. AllFusion Model Navigator,
  7. AllFusion Saphir Option

Чотири пакета – 1, 2, 4, 5 – складають основу і дозволяють здійснювати розробку всіх моделей, наведених у таблиці 1:


Підтримка роботи аналітиків здійснюється:


Можливе використання кожного з основних моделюючих пакетів автономно.

З наведених у таблиці 1 задач моделювання, комплекс AllFusion Process Modeler забезпечує розробку моделей, наведених в осередках 2, 3, 4, 5, 6, 7, 8, 13, 14, (15), 16, (17).

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

Таблиця 2. Інформаційні об’єкти відображення об’єкта моделювання



























































































































№№ Найменування Переклад
1 Налаштування моделі Viewpoint Точка зору (моделі)
2 Purpose Мета (розробки моделі)
3 Scope Межі (моделі)
4 Status (W, D, R, P) Статус моделі
5 AS IS/TO BE Used at – статус
6 Arrow, Name Arrow Ім’я стрілки
7 Activity, Name Activity Функція, робота
8 UOW – Unit of Work Одиниця поведінки (IDEF3)
9 Стандартні діаграми моделі8
10 Node Tree Діаграма “Дерево вузлів”
11 For Exposition Only (FEO) Діаграма “Тільки для демонстрації”
12 OrgChart Організаційна діаграма
13 Swim Lane Діаграма “Плавальна доріжка”
14 Cost Centre Центр витрат
15 Duration Тривалість (здійснення Activity)
16 Frequancy Кратність (функцій, витрат)
17 Input Arrow Стрілка входу
18 Control Arrow Стрілка управління
19 Output Arrow Стрілка виходу
20 Mechanism Arrow і Call Arrow Стрілки механізму
21 Junction Перехрестя (IDEF3)
22 Data Store Накопичувач даних (DFD)
23 External Reference Зовнішня сутність (DFD)
24 Resource Ресурс (кадровий)
25 Role Роль (в процесі роботи в системі)
26 Role Group Рольова група
27 Tipe Arrow Тип стрілки – Precedence, Relational, Object Flow, Bidirectional
28 Off-Page Reference Внестранічная посилання
29 Топологія системи зв’язків об’єктів моделі

Таблиця “Інформаційні об’єкти відображення об’єкта моделювання” представляє необхідний і достатній склад структурних груп інформації, що дозволяє здійснити опис роботи об’єкта моделювання.

Перші п’ять рядків представляють інформацію настройки функціональної моделі

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

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

Поєднання AllFusion Process Modeler і AllFusion Erwin Data Modeler забезпечує комп’ютерну підтримку розробки програмного забезпечення (див. нижню гілку, рис. 1). Така розробка базується на функціональній моделі майбутньої комп’ютерної системи (осередок 6) і її моделі даних (осередок 7). Програмна інтеграція цих моделей забезпечує автоматичну генерацію логічної структури бази даних (БД) розробляється комп’ютерної системи. Подальша інтеграція її з тією чи іншою системою управління базами даних (СКБД) дозволяє генерувати фізичну структуру БД. Створення додатків (Applications – таблиць введення інформації, форм запитів і форм звітів), завершує роботу над створенням нового пакета прикладних програм (ППП).

В процесі розробки AllFusion Data Model Validator забезпечує перевірку коректності моделі даних.

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

Зовнішні зв’язки AllFusion Process Modeler 4.1


Зовнішні зв’язки AllFusion Process Modeler 4.1, здійснювані в процесі розробки функціональної моделі, зумовлюються функціональними взаємовідносинами з середовищем, і служать, в основному, цілям:


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

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

Зовнішні зв’язки AllFusion Process Modeler 4.1 можна розділити на дві групи:


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

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

Існує, однак, деякий, більш-менш визначений і постійний, – якщо не сказати обов’язковий, – коло зовнішніх функціональних зв’язків, головними з яких є зв’язку:


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

До другої групи можуть бути віднесені:


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

AllFusion Process Modeler 4.1 підтримує такі технології обміну даними:


Внеелектронний обмін інформацією, на рівні посилань, здійснюється, також, за допомогою “Стрілець виклику” (Call Arrow).

Сервіси AllFusion Process Modeler 4.1.


AllFusion Process Modeler 4.1 надає системному аналітику цілий ряд сервісів, що полегшують роботу, і роблять її більш ефективною. Підтримуються наступні сервіси.

Рис. 1. Вікно введення і редагування даних про об’єкти функціональної моделі Diagram Object Dictionary Editor

Рис. 2. Діалогове вікно Page Setup (установка сторінки)


Використання FEO – інструментарію


AllFusion Process Modeler 4.1 дозволяє створювати, у складі функціональної моделі, два типи діаграм:


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

Доступ до всіх діаграм моделі, в тому числі – до FEO – діаграм – забезпечується, в AllFusion Process Modeler 4.1 через Diagram Manager.

FEO – діаграми – засіб створення варіантів стандартної діаграми – при збереженні незмінної вихідної стандартної діаграми, що послужила основою для FEO. Редагування стандартної діаграми – при використанні FEO – інструментарію – може стосуватися всіх, без винятку, її елементів. Редагування може полягати в поповненні, видаленні, заміні графіки і тексту.

Цей вид діаграми може бути використаний для різних цілей:


AllFusion Process Modeler 4.1 дозволяє створити на базі однієї стандартної діаграми – кілька FEO.

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

Виняток становить:


FEO – діаграми можуть бути утворені з усіх трьох видів функціональних моделей – IDEF0, IDEF3, DFD.

Використання Box Style.


Починаючи з версії 4.0, Bpwin системний аналітик отримав в своє розпорядження новий засіб оформлення діаграм – Box Style. З його допомогою стає можливим в широких межах змінювати форму боксу – пристанища Activity. Ця можливість заснована на введенні нових, у тому числі призначених для користувача, символів функцій. Ввести нові символи можна на базі користувальницького меню, що містить – у вигляді списку – Більше 40 видів форм для боксу, відмінних від його стандартної форми прямокутника – Рис. 3.

Рис. 3. Вікно Activity Properties, закладка Box Style

У поєднанні зі словником Bitmap – зображень, функція Box Style дозволяє вводити в бокс різні зображення12. Ці зображення можуть бути введені як в стандартний бокс, так і в бокс в будь користувальницької формі.

Введення Bitmap – зображень


Можливість введення в функціональну модель користувальницьких форм боксів (Custom – Shape Image) дозволяє розробляти не тільки IDEF0, DFD, IDEF3 моделі, але також викреслювати блок – схеми, що відповідають стандарту ГОСТ 19.701 – 90.

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

Є широкі можливості створення таких словників – на базі електронних бібліотек зображень та інших джерел. Як приклад можна вказати на збірку COREL Gallery. Add flair to yor word pricessing and presentations. 10,000 Clipart Images jn CD-ROM Канадської фірми COREL CORPORATION, що містить 10 000 електронних зображень, розроблених професіоналами у форматі *. Bmp. Збірка складається з розділів: портрети (бізнесменів, історичних діячів, політиків, спортсменів тощо), авіація, тварини, зображення стрілок, птахи, діти, зв’язок, комп’ютери, символи, електроніка, риби, їжа, фрукти, продукти, прапори, карти, і ін

Іншим варіантом використання Bitmap Dictionary є введення в функціональну модель полностранічних ілюстрацій.

Формування блок – схем алгоритмів і програм


Склад символів меню користувацьких форм боксів дозволяє повністю забезпечити формування блок-схем алгоритмів і програм – відповідно до ГОСТ 19.701-90 / ІСО 5807 – 85.

Треба врахувати, тільки, що в цьому випадку AllFusion Process Modeler 4.1 при обробці інформації блок – схеми не підтримує ніяких угод, передбачених цим стандартом. Забезпечуючи, стандартним для нього чином, обробку введеної при формуванні блок – схеми інформації, AllFusion Process Modeler 4.1 не бачить функціональних відмінностей між символами стандарту, визнаючи всі їх тільки функціями (Activity). У той час, як угодами ГОСТ 19.701-90 передбачена диференціація функцій – залежно від використовуваного для її зображення символу. Всього в ГОСТ 19.701 – 90 передбачено, тільки для моделювання функцій, – не менше 7 символів: умовне перетворення, безумовне перетворення, рішення, стрічковий накопичувач, барабанний накопичувач, монітор, початок циклу …

Крім того, зв’язки в блок – схемах, розроблених в AllFusion Process Modeler 4.1, будуть представлені стрілками, тоді як в ГОСТ 19.701-90 передбачені прості лінії ..

Тим не менш, при необхідності розробки таких документів, може бути використаний AllFusion Process Modeler 4.1.

Навігація по функціональної моделі


В процесі розробки функціональної моделі, а також при подальшій роботі з нею, особливо при великій кількості діаграм в моделі, важливо зберігати орієнтацію по відношенню до моделі – як в цілому, так і у взаєминах окремих діаграм моделі. Особливо істотно це – при роботі з електронною версією моделі, тобто при роботі на комп’ютері, коли традиційні можливості роботи з паперовими документами не можуть бути використані13. Ці традиційні можливості полягають у здатності маніпулювати одночасно кількома листами діаграм. При роботі на комп’ютері ці можливості доводиться замінювати деякими умовностями, що забезпечують взаімосвязних сприйняття інформації функціональної моделі, розподіленої по її окремим документам, тобто орієнтуватися в інформаційному просторі моделі. Упевнена орієнтування в цьому просторі забезпечується в AllFusion Process Modeler 4.1 декількома засобами навігації.


  1. Context. У правому верхньому куті стандартного бланка діаграми розташоване поле CONTEXT. У цьому полі AllFusion Process Modeler 4.1 автоматично генерує графічну схему батьківського діаграми, із зазначенням в лівому нижньому кутку її вузлового номера (див., на малюнку А0), з зачорненим прямокутником на ній, що позначає Activity, яка декомпозирована на поточному дочірньої діаграмі. Ця схема дозволяє орієнтуватися у зв’язку батьківського і дочірньої діаграм. Див Рис. 4.

    Рис. C. Application Life Cycle Management – одне з шести стратегічних напрямів розвитку програмного забезпечення підтримки електронного бізнесу, що розвиваються Computer Associates.


    1 ERD – Entity Relation Diagram
    2 Інтерфейси – зв’язку людини з матеріально – інформаційною системою
    3 CASE – Computer Aided Software Engineering
    4 У цьому розглядаємо поняття моделювання розширено, включаючи найбільш широко поширене опис (моделювання) систем на природному мовою, спеціалізовані системи графічного моделювання, такі, як креслення, та ін Грунтуючись на наступному визначенні моделі: система Б є моделлю системи А, якщо Б відповідає на питання щодо А.
    5 В їх основі предмети шкільного та початкового вузівської освіти предмети – нарисна геометрія та креслення.
    6 Міжнародний стандарт ISO 9001:2000 є текстовим описом роботи системи менеджменту (управління) якістю. Ця система є розвитком традиційної системи технічного контролю – див Дубейковскій В.І. Практика функціонального моделювання з AllFusion Process Modeler 4.1. Де? Навіщо? Як? Москва, ДІАЛОГ-МИФИ, 2004. За своїм змістом, система управління якістю являє опис спеціалізованої системи документообігу, що забезпечує гарантоване залучення персоналу підприємства в постійну участь у забезпеченні якості продукції.
    7 Встановлення відносин підлеглості схемою оргструктури носить неявний характер. Мається на увазі, що розташований в цій схемі ієрархічно нижче працівник підпорядковується розташованому вище, тобто вищерозміщений управляє нижележащим. Однак жодних подробиць, що стосуються кількості та складу каналів управління одного іншим та ін подробиці як правило не наводиться. Наслідком є ​​невизначеність у взаєминах. Власне процедури управління в схемах оргструктур як правило тотально ігноруються.
    8 Кожна діаграма функціональної моделі є самостійним інформаційним об’єктом в силу того, що кожна з них є деякою підсистемою, що інтегрує що входять до неї об’єкти, і створює той чи інший приватний системний ефект.
    9 Передбачена можливість використання однієї з основних СУБД, загальним число до …
    10 Ці звіти (Reports – в термінології першоджерела) є аналогами ЗАПИТІВ СУБД.
    11 В *. Idl – форматі обмін може бути зроблений тільки IDEF0 моделями.
    12 Bitmap – зображення можна вводити в діаграми функціональної моделі після створення відповідного словника Bitmap Dictionary.
    13 Звичайно ці можливості ніколи не стають недоступними. Роздруківка моделі в цілому, або е діаграм доступна на будь-якому етапі роботи. НИ цим періодично доводиться користуватися. Питання, однак, в тому, що неможливо робити це занадто часто …


    Додаткова інформація



    • Детальніше про продукти Computer Associates
    • Детальніше про лінійку інтегрованих засобів моделювання (CASE) – AllFusion Modeling Suite
    • Звернутися в Interface Ltd. за додатковою інформацією / з питання придбання продуктів
    • Придбати продукти Computer Associates в електронному магазині ITshop.ru
    • Курси по продуктам Computer Associates

    Схожі статті:


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

    Коментарів поки що немає.

    Ваш отзыв

    Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

    *

    *