Методологія DATARUN і CASEсистема SILVERRUN розроблені американською фірмою Computer Systems Advisers для забезпечення єдиного методологічного підходу до процесу проектування та його автоматизованої підтримки. Цілями методології є забезпечення концептуальної основи для всього процесу розробки і технології керівництва проектом.
Згідно з методологією DATARUN життєвий цикл розбивається на стадії, пов’язані з результатами виконання основних процесів, визначених за стандартом ISO 12207: формування вимог і планування, концептуальне проектування, специфікація додатків, розроблення, інтеграція та тестування, впровадження, супровід та розвиток. Унікальність концепції полягає в тому, що на кожній стадії виконують лише суттєві роботи, що пришвидшує розробку. Повтори та збитковість у специфікаціях виключаються , створюється керована форма ітеративної розробки, ґрунтована на моделях. Початкові версії об’єктів доступні для безпосереднього використання на подальших фазах проектного циклу.
Інформаційна система розглядається як набір модулів, що виконуються процесорами і взаємодіють із базами даних. Бази даних і процесори можуть розташовуватися централізовано або бути розподіленими. Події в системі можуть ініціюватися зовнішніми сутностями (клієнти) або подіями (кінець місяця чи кварталу). Усі транзакції здійснюються через об’ єкти чи модулі інтерфейсу, що взаємодіють з однією або більше базами даних.
Процес створення ІС передбачає розроблення набору послідовних моделей, кожна з яких є розвитком попередньої і наслідує правила й дані, визначені у більш ранніх моделях, що вможливлює багаторазове використання різних специфікацій на всіх рівнях прикладного проекту:
— BPM (Business Process Model) — модель бізнеспроцесів;
— PDS (Primary Data Structure) — структура первинних даних;
— CDM (Conceptual Data Model) — концептуальна модель даних ;
— SPM (System Process Model) — модель процесів системи;
— ISA (Information System Architecture) — архітектура ІС;
— ADM (Application Data Model) — модель даних додатку;
— IPM (Interface Presentation Model) — модель подання інтерфейсу;
— ISM (Interface Specification Model) — модель специфікації інтерфейсу.
Моделі розробляють за допомогою CASEсистеми Silverrun. Першою в модулі Silverrun BPM (див. далі) створюється модель бізнеспроцесів із використанням нотації BPM. У процесі аналізу та специфікації бізнесфункцій виявляються основні інформаційні об’єкти, що документуються як структури даних, пов’язані з потоками і сховищами моделі. Джерелами для створення таких структур є документи, посадові інструкції, описи виробничих операцій. Ці дані вводять у такому самому вигляді, в якому вони існують в організації. Нормалізацію та видалення надлишковості виконують згодом під час побудові концептуальної моделі даних. Після створення моделі бізнеспроцесів інформація зберігається в репозиторії проекту.
Під час обстеження роботи організації виявляються й документуються структури первинних даних — модель PDS. Первинні дані описують продукти або послуги організації, виконувані операції і ресурси, що споживаються, а також інші зовнішні та внутрішні сутності (працівники, клієнти, ціни, графіки робіт тощо). Структури первинних даних заносять у репозиторій модуля BPM. У моделі бізнеспроцесів вони пов’язані з потоками і сховищами інформації.
На основі структур первинних даних у модулі Silverrun ERX створюється концептуальна модель даних (ERмодель). Від структур первинних даних концептуальна модель відрізняється відсутністю надмірності, стандартизацією найменувань понять і нормалізацією. Ці операції в модулі ERX виконуються за допомогою вбудованої експертної системи. Мета концептуальної моделі даних — описати використовувану інформацію без деталей можливої реалізації в базі даних, але в добре структурованому нормалізованому вигляді.
На основі моделі бізнеспроцесів і концептуальної моделі даних у модулі Silverrun BPM за допомогою спеціальної нотації ISA проектується архітектура ІС. Основний зміст цієї моделі — структурні компоненти системи та навігація між ними. Концептуальна модель даних розбивається на частини , що відповідають додаткам, які входять до складу системи. Для кожного додатку специфікуються дані та функції, що реалізуються.
Перед розробленням додатків слід спроектовувати структуру корпоративної бази даних . Концептуальна модель даних після нормалізації переноситься у модуль реляційного моделювання Silverrun RDM за допомогою спеціального мосту ERXRDM. Перетворення моделі з формату ERX у формат RDM відбувається автоматично без втручання користувача. Після перетворення форматів виходить модель реляційної бази даних, що деталізується шляхом визначення фізичної реалізації (типів даних СКБД, ключів, індексів, тригерів, обмежень посилкової цілісності). Правила оброблення даних можна задавати як безпосередньо мовою програмування СКБД, так і в декларативній формі, не прив’язаній до реалізації. Мости Silverrun до реляційних СКБД перекладають ці декларативні правила мовою потрібної системи, що знижує трудомісткість програмування процедур сервера бази даних і дає змогу генерувати додатки для різних СКБД з однієї специфікації.
Модель системних процесів SPM, що створюється в модулі BPM, детально документує поведінку кожного додатку і визначає реалізацію бізнеспроцесів. Ця модель створюється окремо для кожного додатку і тісно пов’язана з його моделлю даних.
Додаток складається з інтерфейсних об’єктів (екранних форм, звітів, процедур оброблення даних). Кожен інтерфейс системи оперує підмножиною бази даних. Підсхема бази даних для кожного інтерфейсу додатку визначається в модулі RDM у моделі даних додатку ADM, яка також уточнює правила оброблення даних, специфічні для кожного інтерфейсу. Окрема підсхема моделі даних інтерфейсу оформлюється через те, що інтерфейс працює з даними в ненормалізованому вигляді.
Модель подання інтерфейсу IPM — це опис зовнішнього вигляду інтерфейсу з точки зору кінцевого користувача системи у формі документа, що відображає зовнішній вигляд екрана чи структуру звіту, або сам екран (звіт), створений одним із засобів візуальної розробки додатків (мови четвертого покоління 4GL). Оскільки більшість мов 4GL дають змогу швидко створювати працюючі прототипи додатків, користувач може побачити їх на ранніх стадіях проектування.
Після створення підсхем реляційної моделі для додатків проектується детальна структура кожного додатку у вигляді схеми навігації екранів, звітів, процедур пакетної обробки. На даному кроці ця структура деталізується до вказівки конкретних стовпців і таблиць бази даних, правил їх оброблення, виду екранних форм і звітів. Отримана модель детально документує додаток і безпосередньо використовується для програмування специфікованих інтерфейсів.
Згодом, за допомогою засобів розробки додатків відбувається фізичне створення системи — додатки програмуються та інтегруються в ІС.
Методологія DATARUN підтримується такими автоматизованими засобами:
— Software Engineering Companion призначена для керування проектною діяльністю і надає можливість детально описувати ведення проекту, розподіляти проектні ролі серед виконавців, контролювати виконання завдань;
— Software Engineering Guidelines містить у гіпертекстовому форматі детальне викладення технік моделювання даних і бізнесфункцій, проектування баз даних, створення додатків;
— SILVERRUN — автоматизація проектних робіт.
Названі засоби утворюють середовище проектування, в якому кожен учасник може дізнатися зміст і терміни виконання призначеної йому роботи, вивчити техніку її виконання і викликати інструмент (модуль SILVERRUN) для реального її виконання. Керівник проекту може проконтролювати виконання робіт.
Інструментальний засіб Software Engineering Companion (SE) є середовищем, у якому реалізований електронний варіант методології DATARUN. Він надає можливість:
— створити гіпертекстовий опис методології у вигляді ієрархії описів стадій, етапів та операцій розробки;
— створити гіпертекстовий опис усіх методів і методик реалізації процесів життєвого циклу;
— виокремити з гіпертекстового опису ієрархію процесів життєвого циклу для планування та керування проектом створення ІС (ієрархію робіт);
— змінювати гіпертекстові описи життєвого циклу і методів згідно з потребами розробника — проводити авторизацію методології і відстежувати ці зміни в ієрархії робіт, призначеної для керування проектом;
— прив’язати до процесів життєвого циклу інструментальні засоби підтримки цих процесів і забезпечити виклик інструментальних засобів із відповідних екранів гіпертекстового довідника;
— забезпечити перегляд гіпертекстових екранів опису методів, що використовуються, з інструментальних засобів;
— забезпечити підтримку процесу керування розробкою, зокрема за рахунок взаємодії із засобами планування робіт MS Project, оцінювання трудомісткості проекту, відстеження виконання робіт, створення графіків робіт тощо.
Особливо важливими є можливість авторизації методології та інтерактивний доступ будьякого розробника до опису будьякого методу або процесу у потрібний йому момент часу.
Опис методології зазвичай складається з розділу опису процесів життєвого циклу і розділів опису методів і методик. Своєю чергою, опис процесів містить ієрархію описів стадій, етапів та операцій життєвого циклу з обов’язковим описом вихідних компонентів кожного процесу. Вихідний документ, що описує методологію, подається у форматі MS Word, що надає можливість створити опис з будьяким рівнем деталізації, виконати розмітку для створення гіпертексту та авторизації методології у прийнятому стандартному форматі. Гипертекстовий опис подається у форматі MS Help.
CASEсистема SILVERRUN призначена для автоматизації аналізу та проектування ІС і підтримує будьяку методологію, в якій передбачено відокремлену побудову функціональної та інформаційної моделей (діаграм потоків даних і діаграм «сутністьзв’язок»). Налаштування на конкретну методологію здійснюється шляхом вибору потрібного графічного зображення символів моделей і набору правил перевірки проектних специфікацій. У системі є готові настройки для нотацій і методологій
Gane/Sarson, Yourdon/DeMarco, Ward/Mellor, Merise MCT, Merise Flow Schema, Merise OOM, P+, P+ OPAL. Також можна обирати набір правил, що перевіряється процедурою аналізу коректності моделі.
Система складається із трьох основних підсистем (рис. 2.16), кожна з яких є самостійним продуктом і може використовуватися відокремлено:
— BPM (Business Process Modeler) — модуль побудови діаграм потоків даних (стара назва — SILVERRUN DFD Data Flow Diagrammer) — призначений для моделювання бізнеспроцесів з метою документування потоків робіт та інтеграції бізнесзавдань та архітектури даних підприємства. До потоків даних можуть бути приєднані структури даних, а також зовнішні сутності та зв’язки і навіть цілі моделі даних з метою подання, перепроектування та керування всією інформацією компанії та інфраструктурою функцій.
Особливістю системи є можливість використання символьних ієрархічних ідентифікаторів процесів замість числових, а також зручні функції автоматичної перенумерації об’єктів діаграм за порядком розташування на схемі або в указаній користувачем послідовності. Система може будувати дерево процесів і надає можливість перевизначати їх ієрархічну вкладеність переміщенням процесів з одних вузлів дерева в інші. Для аналізу і реінжинірингу бізнеспроцесів можна визначити ресурси, що використовуються, і задати їхню питому вартість. При побудові моделей користувач вказує обсяг використання ресурсів, а система автоматично підраховує вартість кожного процесу з урахуванням вартості його підпроцесів, а також загальну вартість кожного ресурсу за всією моделлю;
— RDM (Relational Data Modeler) — засіб моделювання реляційних даних шляхом побудови діаграм «сутність—зв’язок»;
— ERX (Entity Relationship eXpert) — розширення для модуля
RDM, призначене для визначення ненормалізованих даних і підтримки їх нормалізації у перебігу діалогу користувача із вбудованою в модуль експертною системою, а також автоматичного створення нормалізованих реляційних моделей даних зі структур даних, наявних визначень файлів та бізнесправил. Може відбуватися як класичне проектування бази даних , так і зворотне — схема даних визначається на основі множини джерел . Концептуальні моделі даних і діаграми «сутність—зв’язок», створені в ERX, можуть конвертуватися в реляційні моделі даних і відкриватися в модулі RDM.
Вбудований у модуль RDM генератор схем баз даних дає можливість отримати оператори визначення даних (DDL) для багатьох СКБД, але для повного використання специфіки кожної системи слід користуватися спеціальними інтерфейсами. Зокрема, розроблено інтерфейси до СКБД: Microsoft Access, Microsoft SQL Server, Oracle, Progress, Sybase. За їх допомогою реалізується концептуальне, логічне та фізичне проектування бази даних. Можна також виконати синхронізацію моделей із відповідними базами даних.
Існують інтерфейси із бізнесдодатками (JD Edwards EnterpriseOne, PeopleSoft Enterprise, SAP, Siebel), системами розробки (COBOL, Synon, Uniface) та засобами моделювання (СА ERwin). Такий підхід дає змогу використовувати єдині моделі в ситуаціях, коли різні підрозділи або філії компанії використовують різні СКБД і засоби розробки додатків.
Усі інтерфейси забезпечують завантаження в Silverrun RDM інформації з каталогів відповідних СКБД або мов 4GL, на основі чого відбувається документування, перепроектування або перенесення на нові платформи вже наявних баз даних і прикладних систем. При цьому Silverrun розширює свій внутрішній репозиторій специфічними для цільової системи атрибутами. Після визначення значень цих атрибутів генератор додатків переносить їх до внутрішнього каталогу середовищ розробки або використовує при генеруванні коду мовою SQL. Таким чином можна повністю визначити ядро бази даних із використанням усіх можливостей конкретної СКБД: тригерів, процедур, що зберігаються, обмежень посилкової цілісності тощо. При створенні додатків мовою 4GL дані, перенесені з репозиторію Silverrun, використовують або для автоматичного генерування інтерфейсних об’єктів, або для швидкого створення їх вручну.
Як приклад, на рис. 2.17 наведено модель «сутність—зв’язок» у третій нормальній формі, автоматично побудовану і нормалізовану модулем ERX в результаті діалогу з користувачем.
На рис. 2.18 наведено ту саму модель, перенесену в модуль реляційного моделювання RDM і доопрацьовану для безпосередньої реалізації у реляційній базі даних. У нижній частині символів таблиць показано дії над записами. У схемі бази даних, що буде згенерована інтерфейсом, на їх основі буде створено відповідні тригери. Також у моделі вказуються дії, що виконуються над стовпцями під час операцій зчитування, присвоєння або модифікації значень . Існує можливість визначити глобальні дії на рівні всієї моделі (у схемі бази даних — процедури, що зберігаються) . Таким чином не тільки визначаються конструкції реляційної СКБД, а й об’єктноорієнтоване розширення реляційної моделі.
Для генерування індексів можна обрати будьякі комбінації стовпців таблиць і зв’ язків. SILVERRUN автоматично генерує індекси для первинних і альтернативних ключів, а також оператори контролю посилкової цілісності на основі характеристик зв’язків. У моделі наявні конструкції для підтипів та альтернативних зв’ язків, при цьому немає вимоги щодо належності лише до одного підтипу, що дає змогу моделювати можливі ситуації, які не підпадають під визначення категоризації в таких нотаціях, як, зокрема, IDEF1. Для підтримки різних методологій модуль RDM уможливлює перевизначення нотації.
Різні групи користувачів мають доступ до різних підмножин бази даних і до обмеженого набору операцій над ними. Для моделювання користувацьких (зовнішніх) подань у модулі RDM використовується механізм підсхем. Підсхема — це підмножина моделі даних, доступна конкретному додатку або групі користувачів. Користувач може встановлювати межу між схемою і підсхемою, а також переносити зміни зі схеми до підсхеми і навпаки. Кількість рівнів підсхем не обмежується, можна створювати підсхеми підсхем.
Специфікації схеми або підсхем можна перенести через відповідний інтерфейс у середовище розробки додатків або згенерувати схему бази даних для СКБД, зокрема для моделювання видів екранів або форматів звітів, що не виходить за межі функціональності SILVERRUN, оскільки ці функції специфічні для кожної мови розробки. SILVERRUN передає дані про формати введення, правила редагування, форми подання безпосередньо в репозиторій середовища розробки. Програміст розташовує поля на екранах, коригує SQLзапити, що автоматично генеруються більшістю мов четвертого покоління для цих екранів, визначає систему меню.
Генерування схеми бази даних відбувається шляхом створення файла з SQLоператорами, в які переводяться конструкції моделі даних. Цей файл використовується для фізичного створення бази даних на сервері.
Для інтеграції підсистем SILVERRUN застосовується менеджер репозиторію WRM (Workgroup Repository Manager). У репозиторії зберігаються всі об’єкти та дані діаграм потоків даних, об’єкти і зв’язки діаграм «сутність—зв’язок». Репозиторій також можна доповнювати дескрипторами, визначеними користувачем.
Доступ до репозиторію відбувається через вибір об’єкта звичайним чином (за допомогою миші), а навігація — за допомогою посилань.
У SILVERRUN основою всіх подань є дані. Вони є спільною частиною всіх формалізмів (типів описів) й універсально опрацьовуються всіма модулями. Один і той самий елемент даних у різних поданнях може мати різні назви і формати. Система забезпечує можливість зв’язувати елементи даних різних подань зі спільним елементом (common item), який виражає сенс представленої елементами даних інформації. Такий спільний елемент може стати стовпцем таблиці бази даних у новій системі або просто використовуватися як універсальний термін для зв’язку різних подань.
Для обміну даними з іншими інструментальними засобами проектування, створення спеціалізованих процедур аналізу і перевірки проектних специфікацій, складання спеціалізованих звітів згідно з різними стандартами в Silverrun є три способи виведення проектної інформації у зовнішні файли:
— система звітів — користувач визначає зміст звіту за репозиторієм, інформація записується у файл формату HTML або RTF так, щоб його можна було відкоригувати в текстовому редакторі та/або розмістити в інший звіт;
— система експорту/імпорту — визначаються не лише вміст експортного файла, а й розподільники записів, полів у записах, маркери початку і кінця текстових полів. Файли з указаною структурою можна не лише формувати, а й завантажувати в репозиторій. За допомогою цих функцій здійснюється обмін даними з іншими CASEзасобами, СКБД, текстовими редакторами та електронними таблицями;
— зберігання репозиторію у зовнішніх файлах через ODBCдрайвери. Для доступу до даних репозиторію найпоширеніших СКБД проектна інформація може зберігатися безпосередньо у форматі цих СКБД.
Групова робота підтримується в системі двома способами:
— у стандартній однокористувацькій версії — за допомогою механізму контрольованого розподілу та злиття моделей. Частини моделі передаються різним розробникам і після детального доопрацьовування об’єднуються в єдині специфікації;
— у мережній версії системи здійснюється одночасна групова робота з моделями, що зберігаються в мережному репозиторії. При цьому кілька розробників можуть працювати з однією моделлю, оскільки блокування об’єктів відбувається на рівні її окремих елементів.
SILVERRUN функціонує на платформах Windows, OS/2, Macintosh, Solaris. Між версіями різних платформ можливий обмін даними, що створює передумови для одночасного розроблення в різнорідному середовищі.
Резюме
Керування процесами є відправною точкою проектування ІС, бо визначає зміст усіх майбутніх робіт. Нагромаджені знання з численних методик та необхідність пристосування найкращих практик до специфіки конкретних проектів зумовлюють потребу у відповідних інструментальних засобах. Автоматизовані засоби підтримують визначення процесів, зокрема опис процесів із використанням тих чи інших діаграм і нотацій, та/або містять відповідні керівництва (RUP, RMC, MSF). У разі проведення аналізу процесів деякі інструментальні засоби забезпечують різні форми симуляції. Усі засоби мають можливості редагування шаблонів з метою їх адаптації.
