CASE-технології

Введення

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

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

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

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

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

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

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

необхідність інтеграції існуючих і нових додатків;

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

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

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

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

У 70-х і 80-х роках при розробці ІС досить широко застосовувалася структурна методологія, що надає в розпорядження розробників строгі формалізовані методи опису ІС та прийнятих технічних рішень. Вона заснована на наочній графічній техніці: для опису різного роду моделей ІС використовуються схеми і діаграми. Наочність і строгість коштів структурного аналізу дозволяла розробникам і майбутнім користувачам системи з самого початку неформально брати участь у її створенні, обговорювати і закріплювати розуміння основних технічних рішень. Однак, широке застосування цієї методології та проходження її рекомендацій при розробці конкретних ІС зустрічалося досить рідко, оскільки при неавтоматизованої (ручний) розробці це практично неможливо. Дійсно, вручну дуже важко розробити і графічно представити суворі формальні специфікації системи, перевірити їх на повноту і несуперечність, і тим більше змінити. Якщо все ж таки вдається створити жорстку систему проектних документів, то її переробка при появі серйозних змін практично нездійсненна. Ручна розробка зазвичай породжувала наступні проблеми:

неадекватна специфікація вимог;

нездатність виявляти помилки в проектних рішеннях;

низька якість документації, що знижує експлуатаційні якості;

затяжний цикл і незадовільні результати тестування.

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

Перераховані фактори сприяли появі програмно-технологічних засобів спеціального класу - CASE-засобів, що реалізують CASE-технологію створення і супроводу ІС. Термін CASE (Computer Aided Software Engineering) використовується в даний час в досить широкому сенсі. Первинне значення терміна CASE, обмежене питаннями автоматизації розробки лише програмного забезпечення (ПЗ), в даний час набуло нового змісту, що охоплює процес розробки складних ІС у цілому. Тепер під терміном CASE-засоби розуміються програмні засоби, що підтримують процеси створення і супроводу ІС, включаючи аналіз і формулювання вимог, проектування прикладного ПЗ (додатків) і баз даних, генерацію коду, тестування, документування, забезпечення якості, конфігураційне управління і управління проектом, а також інші процеси. CASE-засоби разом із системним ПЗ і технічними засобами утворюють повну середовище розробки ІС.

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

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

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

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

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

Відповідно до огляду передових технологій (Survey of Advanced Technology), складеним фірмою Systems Development Inc. в 1996 р. за результатами анкетування більше 1000 американських фірм, CASE-технологія в даний час потрапила в розряд найбільш стабільних інформаційних технологій (її використала половина всіх опитаних користувачів більш ніж у третині своїх проектів, з них 85% завершилися успішно). Однак, незважаючи на всі потенційні можливості CASE-засобів, існує безліч прикладів їх невдалого впровадження, в результаті яких CASE-засоби стають "поличні" ПЗ (shelfware). У зв'язку з цим необхідно відзначити наступне:

CASE-засоби не обов'язково дають негайний ефект; він може бути отриманий тільки через якийсь час;

реальні витрати на впровадження CASE-засобів звичайно набагато перевищують витрати на їх придбання;

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

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

широке розмаїття якості і можливостей CASE-засобів;

відносно невеликий час використання CASE-засобів в різних організаціях і брак досвіду їх застосування;

широка різноманітність у практиці впровадження різних організацій;

відсутність детальних метрик і даних для вже виконаних і поточних проектів;

широкий діапазон предметних областей проектів;

різна ступінь інтеграції CASE-засобів в різних проектах.

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

Для успішного впровадження CASE-засобів організація повинна володіти наступними якостями:

Технологія. Розуміння обмеженості існуючих можливостей і здатність прийняти нову технологію;

Культура. Готовність до впровадження нових процесів і взаємовідносин між розробниками та користувачами;

Управління. Чітке керівництво і організованість по відношенню до найбільш важливих етапів і процесів впровадження.

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

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

достовірна оцінка віддачі від інвестицій в CASE-засоби скрутна через відсутність прийнятних метрик і даних з проектів та процесам розробки ПЗ;

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

відсутність повної відповідності між тими процесами і методами, які підтримуються CASE-засобами, і тими, які використовуються в даній організації, може призвести до додаткових труднощів;

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

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

негативне ставлення персоналу до впровадження нової CASE-технології може бути головною причиною провалу проекту.

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

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

високий рівень технологічної підтримки процесів розробки і супроводу ПЗ;

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

прийнятний рівень віддачі від інвестицій в CASE-засоби. 1. Основи методології проектування ІС 1.1. Життєвий цикл з ІВ

Одним з базових понять методології проектування ІС є поняття життєвого циклу її програмного забезпечення (ЖЦ ПЗ). ЖЦ ПЗ - це безперервний процес, який починається з моменту прийняття рішення про необхідність його створення і закінчується в момент його повного вилучення з експлуатації.

Основним нормативним документом, що регламентує ЖЦ ПЗ, є міжнародний стандарт ISO / IEC 12207 [5] (ISO - International Organization of Standardization - Міжнародна організація по стандартизації, IEC - International Electrotechnical Commission - Міжнародна комісія по електротехніці). Він визначає структуру ЖЦ, що містить процеси, дії і завдання, які повинні бути виконані під час створення ПЗ.

Структура ЖЦ ПЗ за стандартом ISO / IEC 12207 базується на трьох групах процесів:

основні процеси ЖЦ ПЗ (придбання, постачання, розробка, експлуатація, супровід);

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

організаційні процеси (управління проектами, створення інфраструктури проекту, визначення, оцінка та поліпшення самого ЖЦ, навчання).

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

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

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

Управління конфігурацією є одним з допоміжних процесів, що підтримують основні процеси життєвого циклу ПЗ, передусім процеси розробки і супроводу ПЗ. При створенні проектів складних ІС, що складаються з багатьох компонентів, кожен з яких може мати різновиди чи версії, виникає проблема обліку їх зв'язків і функцій, створення уніфікованої структури та забезпечення розвитку всієї системи. Управління конфігурацією дозволяє організувати, систематично враховувати і контролювати внесення змін в ПЗ на всіх стадіях ЖЦ. Загальні принципи та рекомендації конфігураційного обліку, планування та управління конфігураціями ПЗ відображені в проекті стандарту ISO 12207-2 [5].

Кожен процес характеризується певними завданнями і методами їх вирішення, вихідними даними, отриманими на попередньому етапі, і результатами. Результатами аналізу, зокрема, є функціональні моделі, інформаційні моделі та відповідні їм діаграми. ЖЦ ПО носить ітераційний характер: результати чергового етапу часто викликають зміни в проектних рішеннях, вироблених на більш ранніх етапах. 1.2. Моделі життєвого циклу ПЗ

Стандарт ISO / IEC 12207 не пропонує конкретну модель ЖЦ і методи розробки ПЗ (під моделлю ЖЦ розуміється структура, що визначає послідовність виконання та взаємозв'язку процесів, дій і завдань, що виконуються протягом ЖЦ. Модель ЖЦ залежить від специфіки ІС та специфіки умов, в яких остання створюється і функціонує). Його регламенти є загальними для будь-яких моделей ЖЦ, методологій і технологій розробки. Стандарт ISO / IEC 12207 описує структуру процесів ЖЦ ПЗ, але не конкретизує в деталях, як реалізувати або виконати дії і завдання, включені в ці процеси.

До теперішнього часу найбільшого поширення набули наступні дві основні моделі ЖЦ:

каскадна модель (70-85 р.р.);

спіральна модель (86-90 р.р.).

У спочатку існували однорідних ІС кожен додаток являло собою єдине ціле. Для розробки такого типу додатків застосовувався каскадний спосіб. Його основною характеристикою є розбиття всієї розробки на етапи, причому перехід з одного етапу на наступний відбувається тільки після того, як буде повністю завершено роботу на поточному (рис. 1.1). Кожен етап завершується випуском повного комплекту документації, достатньої для того, щоб розробка могла бути продовжена іншою командою розробників.

Позитивні сторони використання каскадного підходу полягають у наступному [2]:

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

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

Рис. 1.1. Каскадна схема розробки ПЗ

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

Рис. 1.2. Реальний процес розробки ПЗ за каскадної схемою

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

Для подолання перелічених проблем була запропонована спіральна модель ЖЦ [10] (рис. 1.3), що робить упор на початкові етапи ЖЦ: аналіз та проектування. На цих етапах реалізація технічних рішень перевіряється шляхом створення прототипів. Кожен виток спіралі відповідає створенню фрагмента або версії ПЗ, на ньому уточнюються цілі і характеристики проекту, визначається його якість і плануються роботи наступного витка спіралі. Таким чином поглиблюються і послідовно конкретизуються деталі проекту і в результаті вибирається обгрунтований варіант, який доводиться до реалізації.

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

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

Рис 1.3. Спіральна модель ЖЦ 1.3. Методології та технології проектування ІС 1.3.1. Загальні вимоги до методології та технології

Методології, технології та інструментальні засоби проектування (CASE-засоби) складають основу проекту будь-ІВ. Методологія реалізується через конкретні технології та підтримують їх стандарти, методики та інструментальні засоби, які забезпечують виконання процесів ЖЦ.

Технологія проектування визначається як сукупність трьох складових:

покрокової процедури, яка визначає послідовність технологічних операцій проектування (рис. 1.4);

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

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

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

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

Технологія проектування, розробки і супроводу ІС повинна задовольняти наступним загальним вимогам:

технологія повинна підтримувати повний ЖЦ ПЗ;

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

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

технологія повинна забезпечувати можливість ведення робіт з проектування окремих підсистем невеликими групами (3-7 осіб). Це обумовлено принципами керованості колективу і підвищення продуктивності за рахунок мінімізації числа зовнішніх зв'язків;

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

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

технологія повинна забезпечувати незалежність виконуваних проектних рішень від засобів реалізації ІС (систем управління базами даних (СКБД), операційних систем, мов і систем програмування);

технологія повинна бути підтримана комплексом узгоджених CASE-засобів, що забезпечують автоматизацію процесів, які виконуються на всіх стадіях ЖЦ. Загальний підхід до оцінки і вибору CASE-засобів описаний у розділі 4, приклади комплексів CASE-засобів - у підрозділі 5.7.

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

стандарт проектування;

стандарт оформлення проектної документації;

стандарт для користувача інтерфейсу.

Стандарт проектування повинен встановлювати:

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

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

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

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

Стандарт оформлення проектної документації повинен встановлювати:

комплектність, склад і структуру документації на кожній стадії проектування;

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

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

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

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

Стандарт інтерфейсу користувача повинен встановлювати:

правила оформлення екранів (шрифти і колірна палітра), склад і розташування вікон і елементів управління;

правила використання клавіатури і миші;

правила оформлення текстів допомоги;

перелік стандартних повідомлень;

правила обробки реакції користувача. 1.3.2. Методологія RAD

Одним з можливих підходів до розробки ПЗ в рамках спіральної моделі ЖЦ є отримала останнім часом широкого поширення методологія швидкої розробки додатків RAD (Rapid Application Development). Під цим терміном зазвичай розуміється процес розробки ПЗ, що містить 3 елементи:

невелику команду програмістів (від 2 до 10 осіб);

короткий, але ретельно пророблений виробничий графік (від 2 до 6 міс.);

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

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

Життєвий цикл ПЗ за методологією RAD складається з чотирьох фаз:

фаза аналізу і планування вимог;

фаза проектування;

фаза побудови;

фаза впровадження.

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

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

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

загальна інформаційна модель системи;

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

точно визначені за допомогою CASE-засоби інтерфейси між автономно розробляються підсистемами;

побудовані прототипи екранів, звітів, діалогів.

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

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

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

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

визначається необхідність розподілу даних;

проводиться аналіз використання даних;

виробляється фізичне проектування бази даних;

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

визначаються способи збільшення продуктивності;

завершується розробка документації проекту.

Результатом фази є готова система, що задовольняє всіх узгоджених вимогам.

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

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

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

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

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

Як підсумок перерахуємо основні принципи методології RAD:

розробка додатків итерациями;

необов'язковість повного завершення робіт на кожному з етапів життєвого циклу;

обов'язкове залучення користувачів до процесу розробки ІС;

необхідне застосування CASE-засобів, що забезпечують цілісність проекту;

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

необхідне використання генераторів коду;

використання прототипування, що дозволяє повніше з'ясувати і задовольнити потреби кінцевого користувача;

тестування і розвиток проекту, здійснювані одночасно з розробкою;

ведення розробки нечисленної добре керованою командою професіоналів;

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

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

Усі найбільш поширені методології структурного підходу [9,11,12,13] базуються на ряді загальних принципів [3]. В якості двох базових принципів використовуються наступні:

принцип "розділяй і володарюй" - принцип вирішення складних проблем шляхом їх розбиття на безліч менших незалежних задач, легких для розуміння і вирішення;

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

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

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

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

принцип несуперечності - полягає в обгрунтованості та узгодженості елементів;

принцип структурування даних - полягає в тому, що дані повинні бути структуровані і ієрархічно організовані.

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

SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми (підрозділ 2.2);

DFD (Data Flow Diagrams) діаграми потоків даних (підрозділ 2.3);

ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок" (підрозділ 2.4).

На стадії проектування ІС моделі розширюються, уточнюються і доповнюються діаграмами, що відбивають структуру програмного забезпечення: архітектуру ПЗ, структурні схеми програм і діаграми екранних форм.

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

Методологія SADT розроблена Дугласом Россом і отримала подальший розвиток у роботі [4]. На її основі розроблена, зокрема, відома методологія IDEF0 (Icam DEFinition), яка є основною частиною програми ICAM (Інтеграція комп'ютерних та промислових технологій), що проводиться за ініціативою ВПС США.

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

графічне представлення блокового моделювання. Графіка блоків і дуг SADT-діаграми відображає функцію у вигляді блоку, а інтерфейси входу / виходу представляються дугами, відповідно входять у блок і виходять з нього. Взаємодія блоків один з одним описуються за допомогою інтерфейсних дуг, що виражають "обмеження", які в свою чергу визначають, коли і яким чином функції виконуються і управляються;

строгість і точність. Виконання правил SADT вимагає достатньої строгості й точності, не накладаючи в той же час надмірних обмежень на дії аналітика. Правила SADT включають:

обмеження кількості блоків на кожному рівні декомпозиції (правило 3-6 блоків);

зв'язність діаграм (номери блоків);

унікальність міток і найменувань (відсутність повторюваних імен);

синтаксичні правила для графіки (блоків і дуг);

поділ входів та управлінь (правило визначення ролі даних).

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

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

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

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

Рис. 2.1. Функціональний блок та інтерфейсні дуги

На малюнку 2.2, де наведено чотири діаграми та їх взаємозв'язку, показана структура SADT-моделі. Кожен компонент моделі може бути декомпозирована на іншій діаграмі. Кожна діаграма ілюструє "внутрішню будову" блоку на батьківській діаграмі. 2.2.2. Ієрархія діаграм

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

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

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

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

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

Рис. 2.2. Структура SADT-моделі. Декомпозиція діаграм

На малюнках 2.3 - 2.5 представлені різні варіанти виконання функцій і з'єднання дуг з блоками.

Рис. 2.3. Одночасне виконання

Рис. 2.4. Відповідність має бути повним і несуперечливим

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

На SADT-діаграмах не вказані явно ні послідовність, ні час. Зворотні зв'язки, ітерації, що тривають процеси і перекриваються (за часом) функції можуть бути зображені з допомогою дуг. Зворотні зв'язки можуть виступати у вигляді коментарів, зауважень, виправлень і т.д. (Рисунок 2.5).

Рис. 2.5. Приклад зворотного зв'язку

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

Рис. 2.6. Приклад механізму

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

Для того, щоб вказати положення будь-якої діаграми чи блоку в ієрархії, використовуються номери діаграм. Наприклад, А21 є діаграмою, яка деталізує блок 1 на діаграмі А2. Аналогічно, А2 деталізує блок 2 на діаграмі А0, яка є самої верхньої діаграмою моделі. На малюнку 2.7 показано типове дерево діаграм.

Рис. 2.7. Ієрархія діаграм 2.2.3. Типи зв'язків між функціями

Одним з важливих моментів при проектуванні ІС за допомогою методології SADT є точна узгодженість типів зв'язків між функціями. Розрізняють принаймні сім типів зв'язування:

Нижче кожен тип зв'язку коротко визначено і проілюстрований за допомогою типового прикладу з SADT.

(0) Тип випадкової зв'язності: найменш бажаний.

Випадкова зв'язність виникає, коли конкретна зв'язок між функціями мала або повністю відсутня. Це відноситься до ситуації, коли імена даних на SADT-дугах в одній діаграмі мають малу зв'язок один з одним. Крайній варіант цього випадку показаний на малюнку 2.8.

Рис. 2.8. Випадкова зв'язність

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

(2) Тип тимчасової зв'язності. Пов'язані за часом елементи виникають внаслідок того, що вони представляють функції, пов'язані в часі, коли дані використовуються одночасно або функції включаються паралельно, а не послідовно.

(3) Тип процедурної зв'язності. Процедурно-зв'язані елементи з'являються згрупованими разом внаслідок того, що вони виконуються протягом однієї і тієї ж частини циклу або процесу. Приклад процедурно-зв'язаної діаграми наведено на малюнку 2.9.

Рис. 2.9. Процедурна зв'язність

(4) Тип комунікаційної зв'язності. Діаграми демонструють комунікаційні зв'язки, коли блоки групуються внаслідок того, що вони використовують одні і ті ж вхідні дані та / або роблять одні й ті ж вихідні дані (рисунок 2.10).

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

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

У математичних термінах необхідна умова для найпростішого типу функціональної зв'язності, показаної на малюнку 2.12, має наступний вигляд: C = g (B) = g (f (A))

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

Рис. 2.12. Функціональна зв'язність

2.3. Моделювання потоків даних (процесів)

В основі даної методології (методології Gane / Sarson [11]) лежить побудова моделі аналізованої ІС - проектованої чи реальною. Відповідно до методології модель системи визначається як ієрархія діаграм потоків даних (ДПД або DFD), що описують асинхронний процес перетворення інформації від її введення в систему до видачі користувачеві. Діаграми верхніх рівнів ієрархії (контекстні діаграми) визначають основні процеси або підсистеми ІС з зовнішніми входами і виходами. Вони деталізуються за допомогою діаграм нижнього рівня. Така декомпозиція триває, створюючи багаторівневу ієрархію діаграм, до тих пір, поки не буде досягнутий такий рівень декомпозиції, на якому процес стають елементарними і деталізувати їх далі неможливо.

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

зовнішні сутності;

системи / підсистеми;

процеси;

накопичувачі даних;

потоки даних. 2.3.1. Зовнішні сутності

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

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

Рис. 2.13. Зовнішня сутність 2.3.2. Системи і підсистеми

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

Підсистема (або система) на контекстній діаграмі зображується наступним чином (рисунок 2.14).

Рис. 2.14. Підсистема

Номер підсистеми служить для її ідентифікації. У центрі імені вводиться найменування підсистеми у вигляді пропозиції з підметом і відповідними визначеннями і доповненнями. 2.3.3. Процеси

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

Процес на діаграмі потоків даних змальовується, як показано на малюнку 2.15.

Рис. 2.15. Процес

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

"Ввести відомості про клієнтів";

"Видати інформацію про поточні витрати";

"Перевірити кредитоспроможність клієнта".

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

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

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

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

Рис. 2.16. Накопичувач даних

Накопичувач даних ідентифікується буквою "D" і довільним числом. Ім'я накопичувача вибирається з міркування найбільшою інформативності для проектувальника.

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

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

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

Рис. 2.17. Потік даних 2.3.6. Побудова ієрархії діаграм потоків даних

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

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

наявність великої кількості зовнішніх сутностей (десять і більше);

розподілена природа системи;

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

Для складних ІС будується ієрархія контекстних діаграм. При цьому контекстна діаграма верхнього рівня містить не єдиний головний процес, а набір підсистем, з'єднаних потоками даних. Контекстні діаграми наступного рівня деталізують контекст і структуру підсистем.

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

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

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

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

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

правило нумерації - означає, що при деталізації процесів повинна підтримуватися їх ієрархічна нумерація. Наприклад, процеси, які деталізують процес з номером 12, отримують номери 12.1, 12.2, 12.3 і т.д.

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

Миниспецификация є кінцевою вершиною ієрархії ДПД. Рішення про завершення деталізації процесу і використанні миниспецификации приймається аналітиком виходячи з наступних критеріїв:

наявності у процесу відносно невеликої кількості вхідних і вихідних потоків даних (2-3 потоку);

можливості опису перетворення даних процесом у вигляді послідовного алгоритму;

виконання процесом єдиною логічного функції перетворення вхідної інформації у вихідну;

можливості опису логіки процесу за допомогою миниспецификации невеликого обсягу (не більше 20-30 рядків).

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

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

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

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

Нотація ERD була вперше введена П. Ченом (Chen) і отримала подальший розвиток у роботах Баркера [8]. Метод Баркера буде викладатися на прикладі моделювання діяльності компанії з торгівлі автомобілями. Нижче наведені витримки з інтерв'ю, проведеного з персоналом компанії.

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

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

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

Перший крок моделювання - вилучення інформації з інтерв'ю і виділення сутностей.

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

Рис. 2.18. Графічне зображення сутності

Кожна сутність повинна мати унікальний ідентифікатор. Кожен екземпляр сутності повинен однозначно ідентифікуватися і відрізнятися від всіх інших примірників даного типу сутності. Кожна сутність повинна володіти деякими властивостями:

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

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

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

кожна сутність може мати будь-якою кількістю зв'язків з іншими сутностями моделі.

Звертаючись до наведених вище уривків із інтерв'ю, видно, що сутності, які можуть бути ідентифіковані з головним менеджером - це автомашини і продавці. Продавцю важливі автомашини та пов'язані з їх продажем дані. Для адміністратора важливі покупці, автомашини, продавці і контракти. Виходячи з цього, виділяються 4 сутності (автомашина, продавець, покупець, контракт), які зображуються на діаграмі таким чином (малюнок 2.19).

Рис. 2.19.

Наступним кроком моделювання є ідентифікація зв'язків.

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

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

Наприклад, зв'язок предмету з контрактом може бути виражена таким чином:

продавець може отримати винагороду за 1 або більше контрактів;

контракт має бути ініційований рівно одним продавцем.

Ступінь зв'язку та обов'язковість графічно зображаються такий спосіб (рис. 2.20).

Описавши також зв'язки інших сутностей, отримаємо наступну схему (рисунок 2.22).

Рис. 2.22.

Останнім кроком моделювання є ідентифікація атрибутів.

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

Атрибут може бути або обов'язковим, або необов'язковим (малюнок 2.23). Обов'язковість означає, що атрибут не може приймати невизначених значень (null values). Атрибут може бути або описовим (тобто звичайним дескриптором сутності), або входити до складу унікального ідентифікатора (первинного ключа).

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

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

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

З урахуванням наявної інформації доповнимо побудовану раніше діаграму (рисунок 2.25).

Крім перерахованих основних конструкцій модель даних може містити ряд додаткових.

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

Взаємно виключають зв'язку: кожен екземпляр сутності бере участь тільки в одній зв'язку з групи взаємно виключають зв'язків (рисунок 2.27).

Рис. 2.25.

Рекурсивна зв'язок: сутність може бути пов'язана сама з собою (малюнок 2.28).

Неперемещаемие (non-transferrable) зв'язку: примірник сутності не може бути перенесений з одного примірника зв'язку в іншій (рисунок 2.29).

Рис. 2.29. Неперемещаемая зв'язок 2.4.2. Методологія IDEF1

Метод IDEF1, розроблений Т. Ремей (T. Ramey), також заснований на підході П. Чена і дозволяє побудувати модель даних, еквівалентну реляційної моделі в третій нормальній формі. В даний час на основі вдосконалення методології IDEF1 створена її нова версія - методологія IDEF1X. IDEF1X розроблена з урахуванням таких вимог, як простота вивчення і можливість автоматизації. IDEF1X-діаграми використовуються поруч поширених CASE-засобів (зокрема, ERwin, Design / IDEF).

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

Рис. 2.30. Сутності

Кожній сутності присвоюється унікальне ім'я та номер, розділяються косою рисою "/" і поміщаються над блоком.

Зв'язок може додатково визначатися за допомогою вказівки ступеня або потужності (кількості примірників сутності-нащадка, яке може існувати для кожного екземпляра сутності-предка). У IDEF1X можуть бути виражені такі потужності зв'язків:

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

кожен примірник сутності-предка повинен мати не менше одного пов'язаного з нею примірника сутності-нащадка;

кожен примірник сутності-предка повинен мати не більше одного пов'язаного з нею примірника сутності-нащадка;

кожен примірник сутності-предка пов'язаний з деяким фіксованим числом екземплярів сутності-нащадка.

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

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

Рис. 2.31. Потужність зв'язку

Идентифицирующая зв'язок між сутністю-батьком і сутністю-нащадком зображується суцільною лінією (рисунок 2.32). Сутність-нащадок в ідентифікує зв'язку є залежною від ідентифікатора сутністю. Сутність-батько в ідентифікує зв'язку може бути як незалежної, так і залежною від ідентифікатора сутністю (це визначається її зв'язками з іншими сутностями).

Рис. 2.32. Идентифицирующая зв'язок

Пунктирна лінія зображує неидентифицирующей зв'язок (малюнок 2.33). Сутність-нащадок в неидентифицирующей зв'язку буде незалежною від ідентифікатора, якщо вона не є також сутністю-нащадком в якій-небудь ідентифікує зв'язку.

Рис. 2.33. Неидентифицирующей зв'язок

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

Рис. 2.34. Атрибути і первинні ключі

Сутності можуть мати також зовнішні ключі (Foreign Key), які можуть використовуватися в якості частини або цілого первинного ключа або неключових атрибута. Зовнішній ключ зображується за допомогою приміщення всередину блоку сутності імен атрибутів, після яких слідують букви FK в дужках (рисунок 2.35).

Рис. 2.35. Приклади зовнішніх ключів 3. Характеристики CASE-засобів 3.1. Silverrun + JAM 3.1.1. Silverrun

CASE-засіб Silverrun американської фірми Сomputer Systems Advisers, Inc. (CSA) використовується для аналізу і проектування ІС бізнес-класу [22] і орієнтоване більшою мірою на спіральну модель ЖЦ. Воно застосовується для підтримки будь-якої методології, заснованої на роздільному побудові функціональної та інформаційної моделей (діаграм потоків даних і діаграм "сутність-зв'язок").

Налаштування на конкретну методологію забезпечується вибором необхідної графічної нотації моделей і набору правил перевірки проектних специфікацій. У системі є готові налаштування для найбільш поширених методологій: DATARUN (основна методологія, підтримувана Silverrun), GanCE = "Times New Roman"> e / Sarson, Yourdon / DeMarco, Merise, Ward / Mellor, Information Engineering. Для кожного поняття, введеного в проекті є можливість додавання власних описувачів. Архітектура Silverrun дозволяє нарощувати середовище розробки в міру необхідності.

Структура та функції

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

Модуль побудови моделей бізнес-процесів у формі діаграм потоків даних (BPM - Business Process Modeler) дозволяє моделювати функціонування обстежуваної організації або створюваної ІС. У модулі BPM забезпечена можливість роботи з моделями великої складності: автоматична перенумерація, робота з деревом процесів (включаючи візуальне перетягання гілок), від'єднання та приєднання частин моделі для колективної розробки. Діаграми можуть зображуватися у кількох зумовлених нотациях, включаючи Yourdon / DeMarco і Gane / Sarson. Є також можливість створювати власні нотації, в тому числі додавати до числа зображуваних на схемі дескрипторів певні користувачем поля.

Модуль концептуального моделювання даних (ERX - Entity-Relationship eXpert) забезпечує побудова моделей даних "сутність-зв'язок", не прив'язаних до конкретної реалізації. Цей модуль має вбудовану експертну систему, що дозволяє створити коректний нормалізовану модель даних за допомогою відповідей на змістовні питання про взаємозв'язок даних. Можливо автоматична побудова моделі даних з описів структур даних. Аналіз функціональних залежностей атрибутів дає можливість перевірити відповідність моделі вимогам третьої нормальної форми і забезпечити їх виконання. Перевірена модель передається в модуль RDM.

Модуль реляційного моделювання (RDM - Relational Data Modeler) дозволяє створювати деталізовані моделі "сутність-зв'язок", призначені для реалізації в реляційної базі даних. У цьому модулі документуються всі конструкції, пов'язані з побудовою бази даних: індекси, тригери, збережені процедури і т.д. Гнучка змінна нотація і розширюваність сховища дозволяють працювати з будь-якої методології. Можливість створювати подсхеми відповідає підходу ANSI SPARC до подання схеми бази даних. Мовою підсхем моделюються як вузли розподіленої обробки, так і нестандартні уявлення. Цей модуль забезпечує проектування і повне документування реляційних баз даних.

Менеджер репозиторія робочої групи (WRM - Workgroup Repository Manager) застосовується як словник даних для зберігання загальною для всіх моделей інформації, а також забезпечує інтеграцію модулів Silverrun в єдине середовище проектування.

Платою за високу гнучкість і різноманітність образотворчих засобів побудови моделей є такий недолік Silverrun, як відсутність жорсткого взаємного контролю між компонентами різних моделей (наприклад, можливості автоматичного розповсюдження змін між DFD різних рівнів декомпозиції). Слід, однак, відзначити, що цей недолік може мати істотне значення тільки в разі використання каскадної моделі ЖЦ ПЗ.

Взаємодія з іншими засобами

Для автоматичної генерації схем баз даних у Silverrun існують мости до найбільш поширеним СУБД: Oracle, Informix, DB2, Ingres, Progress, SQL Server, SQLBase, Sybase. Для передачі даних в засоби розробки додатків є мости до мов 4GL: JAM, PowerBuilder, SQL Windows, Uniface, NewEra, Delphi. Всі мости дозволяють завантажити в Silverrun RDM інформацію з каталогів відповідних СУБД або мов 4GL. Це дозволяє документувати, перепроектувати або переносити на нові платформи вже перебувають в експлуатації бази даних і прикладні системи. При використанні мосту Silverrun розширює свій внутрішній репозиторій специфічними для цільової системи атрибутами. Після визначення значень цих атрибутів генератор додатків переносить їх у внутрішній каталог середовища розробки або використовує при генерації коду на мові SQL. Таким чином можна повністю визначити ядро ​​бази даних з використанням всіх можливостей конкретної СУБД: тригерів, збережених процедур, обмежень посилальної цілісності. При створенні програми на мові 4GL дані, перенесені з репозиторію Silverrun, використовуються або для автоматичної генерації інтерфейсних об'єктів, або для швидкого їх створення вручну.

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

Система звітів. Можна, визначивши вміст звіту по репозиторію, видати звіт в текстовий файл. Цей файл можна потім завантажити в текстовий редактор або включити в інший звіт;

Система експорту / імпорту. Для більш повного контролю над структурою файлів в системі експорту / імпорту є можливість визначати не тільки вміст експортного файлу, але і роздільники записів, полів в записах, маркери початку і кінця текстових полів. Файли з вказаною структурою можна не тільки формувати, але і завантажувати в репозиторій. Це дає можливість обмінюватися даними з різними системами: іншими CASE-засобами, СУБД, текстовими редакторами та електронними таблицями;

Зберігання сховища в зовнішніх файлах через ODBC-драйвери. Для доступу до даних сховища з найбільш поширених систем управління базами даних забезпечена можливість зберігати всю проектну інформацію безпосередньо у форматі цих СУБД.

Групова робота

Групова робота підтримується в системі Silverrun двома способами:

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

Мережева версія Silverrun дозволяє здійснювати одночасну групову роботу з моделями, що зберігаються в мережевому репозиторії на базі СУБД Oracle, Sybase або Informix. При цьому декілька розробників можуть працювати з однією і тією ж моделлю, оскільки блокування об'єктів відбувається на рівні окремих елементів моделі.

Середовище функціонування

Є реалізації Silverrun трьох платформ - MS Windows, Macintosh і OS / 2 Presentation Manager - з можливістю обміну проектними даними між ними.

Для функціонування в середовищі Windows необхідно мати комп'ютер з процесором моделі не нижче i486 і оперативну пам'ять обсягом не менше 8 Мб (рекомендується 16 Мб). На диску повна інсталяція Silverrun займає 20 Мб. 3.1.2. JAM

Засіб розробки додатків JAM [28] (JYACC's Application Manager) - продукт фірми JYACC (США). В даний час поставляється версія JAM 7 і готується до виходу JAM 8.

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

Структура та функції

JAM має модульну структуру і складається з наступних компонент:

Ядро системи;

JAM / DBi - спеціалізовані модулі інтерфейсу до баз даних (JAM / DBi-Oracle, JAM / DBi-Informix, JAM / DBi-ODBC і т.д.);

JAM / RW - модуль генератора звітів;

JAM / CASEi - спеціалізовані модулі інтерфейсу до CASE-засобів (JAM / CASE-TeamWork, JAM / CASE-Innovator і т.д.);

JAM / TPi - спеціалізовані модулі інтерфейсу до менеджерів транзакцій (наприклад, JAM / TPi-Server TUXEDO і т.д.);

Jterm - спеціалізований емулятор X-термінала.

Ядро системи (власне, сам JAM) є закінченим продуктом і може самостійно використовуватися для розробки додатків. Всі інші модулі є додатковими і самостійно використовуватися не можуть.

Ядро системи включає в себе наступні основні компоненти:

редактор екранів. До складу редактора екранів входять: середовище розробки екранів, візуальний репозиторій об'єктів, власна СУБД JAM - JDB, менеджер транзакцій, відладчик, редактор стилів;

редактор меню;

набір допоміжних утиліт;

кошти виготовлення промислової версії програми.

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

Редактор меню дозволяє розробляти і налагоджувати системи меню. Реалізована можливість побудови піктографічних меню (так звані toolbar). Призначення кожного конкретного меню тому чи іншому об'єкту програми виконується в редакторі екранів.

У ядро ​​JAM вбудована однокористувальницька реляційна СУБД JDB. Основним призначенням JDB є Прототипування додатків в тих випадках, коли робота зі штатною СУБД неможлива або недоцільна. У JDB реалізований необхідний мінімум можливостей реляційних СУБД крім індексів, збережених процедур, тригерів і уявлень (view). За допомогою JDB можна побудувати БД, ідентичну цільової БД (з точністю до відсутніх в JDB можливостей) і розробити значну частину програми.

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

Утиліти JAM включають три групи:

конвертори файлів екранів JAM в текстові. JAM зберігає екрани у вигляді двійкових файлів власного формату. У ряді випадків (наприклад для виготовлення програмної документації проекту) необхідно текстовий опис екранів;

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

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

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

Програми, розроблені з використанням JAM, не вимагають так званих виконавчих (run-time) систем і можуть бути виготовлені у вигляді виконуваних модулів. Для цього розробник повинен мати компілятор C і редактор зв'язків. Для виготовлення промислової версії до складу JAM входить файл збірки (makefile), вихідні тексти (на мові C) ряду модулів програми і необхідні бібліотеки.

JAM містить вбудована мова програмування JPL (JAM Procedural Language), за допомогою якого в разі потреби можна написати модулі, що реалізують специфічні дії. Дана мова є інтерпретованою, що спрощує налагодження. Існує можливість обміну інформацією між середовищем візуально побудованого програми і такими модулями. Крім того, в JAM реалізована можливість підключення зовнішніх модулів, написаних на якій-небудь мові, сумісним з проблем функцій з мовою C.

З точки зору реалізації логіки додатка JAM є подієво-орієнтованою системою. У JAM визначений набір подій, що включає відкриття та закриття вікон, натискання клавіші клавіатури, спрацьовування системного таймера, отримання і передача управління кожним елементом екрана. Розробник реалізує логіку програми шляхом визначення обробника кожної події. Наприклад, обробник події "натискання кнопки на екрані" (мишею або за допомогою клавіатури) може відкрити наступне екранне вікно. Обробники подій в JAM можуть бути як вбудовані функції JAM, так і функції, написані розробником на C або JPL. Набір вбудованих функцій включає в себе більше 200 функцій різного призначення. Вбудовані функції доступні для дзвінків з функцій, написаних як на JPL, так і на C.

Промислова версія програми, розробленого за допомогою JAM, включає в себе наступні компоненти:

виконуваний модуль інтерпретатора програми. У цей модуль можуть бути вбудовані функції, написані розробниками на мовами 3-го покоління;

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

зовнішні JPL-модулі. Можуть поставлятися у вигляді текстових файлів або в прекомпільованних вигляді, причому прекомпільованних зовнішні JPL-модулі можуть бути як у вигляді окремих файлів, так і в складі бібліотек екранів;

файли конфігурації програми - файли конфігурації клавіатури і терміналу, файл системних повідомлень, файл загальної конфігурації.

Взаємодія з іншими засобами

Безпосередня взаємодія з СУБД реалізують модулі JAM / DBi (Data Base interface). Способи реалізації взаємодії в JAM поділяються на два класи: ручні та автоматичні. При ручному способі розробник програми самостійно пише запити на SQL, в яких як джерелами, так і адресатами прийому результатів виконання запиту може бути як інтерфейсні елементи візуально спроектованого зовнішнього рівня, так і внутрішні, невидимі для кінцевого користувача змінні. Автоматичний режим, реалізований менеджером транзакцій JAM, здійснимо для типових і найбільш розповсюджених видів операцій з БД, так званих QBE (Query By Example - запити на зразок), з урахуванням досить складних взаємозв'язків між таблицями БД і автоматичним управлінням атрибутами екранних полів вводу / виводу в Залежно від виду транзакції (читання, запис і т.д.), у якій бере участь згенерований запит.

JAM дозволяє будувати програми для роботи більш ніж з 20 СУБД: ORACLE, Informix, Sybase, Ingres, InterBase, NetWare SQL Server, Rdb, DB2, ODBC-сумісні СУБД і ін

Відмінною рисою JAM є високий рівень переносимості додатків між різними платформами (MS DOS / MS Windows, SunOS, Solaris (i80x86, SPARC), HP-UX, AIX, VMS / Open VMS та ін.) Може знадобитися лише "перемалювати" статичні текстові поля на екранах з російським текстом при перенесенні між середовищами DOS-Windows-UNIX. Крім того, переносимість полегшується тим, що в JAM програми розробляються для віртуальних пристроїв введення / виведення, а не для фізичних. Таким чином при перенесенні додатки з платформи на платформу, як правило, потрібно лише визначити відповідність між фізичними пристроями вводу / виводу та їх логічними уявленнями для програми.

Використання SQL як засоби взаємодії з СУБД також створює передумови для забезпечення переносимості між СУБД. За умови перенесення структури самої БД в ряді випадків додатки можуть не вимагати ніякої модифікації, за винятком ініціалізації сеансу роботи. Така ситуація може скластися в тому випадку, якщо в додатку не використовувалися специфічні для тієї чи іншої СУБД розширення SQL.

При зростанні навантаження на систему і складності вирішуваних завдань (розподіленість і гетерогенність використовуваних ресурсів, кількість одночасно підключених користувачів, складність логіки додатка) застосовується трехзвенная модель архітектури "клієнт-сервер" з використанням менеджерів транзакцій. Компоненти JAM / TPi-Client і JAM / TPi-Server дозволяють досить просто перейти на триланкову модель. При цьому ключову роль відіграє модуль JAM / TPi-Server, так як основна трудність впровадження триланкової моделі полягає в реалізації логіки додатка в сервісах менеджерів транзакцій.

Інтерфейс JAM / CASE подібний до інтерфейсу до баз даних і дозволяє здійснити обмін інформацією між репозиторієм об'єктів JAM і репозиторієм CASE-засоби аналогічно тому, як структура БД імпортується в репозиторій JAM безпосередньо з БД. Відмінність полягає в тому, що в разі інтерфейсу до CASE цей обмін є двонаправленим. Крім модулів JAM / CASEi, існує також модуль JAM / CASEi Developer's Kit. За допомогою цього модуля можна самостійно розробити інтерфейс (тобто спеціалізований модуль JAM / CASEi) для конкретного CASE-засоби, якщо готового модуля JAM / CASEi для нього не існує.

Міст (інтерфейс) Silverrun-RDM JAM реалізує взаємодію між CASE-засобом Silverrun і JAM (перенесення схеми бази даних і екранних форм докладання між CASE-засобом Silverrun-RDM і JAM версії 7.0). Даний програмний продукт має 2 режиму роботи:

прямий режим (Silverrun-RDM-> JAM) призначений для створення об'єктів CASE-словника і елементів репозиторію JAM на основі подання схем у Silverrun-RDM. У цьому режимі міст дозволяє, виходячи з уявлення моделей даних інтерфейсу в Silverrun-RDM, виробляти генерацію екранів і елементів репозиторію JAM. Міст перетворить таблиці і відносини реляційних схем RDM в послідовність об'єктів JAM відповідних типів. Методика побудови моделей даних інтерфейсу в Silverrun-RDM передбачає застосування механізму підсхем для прототипування екранів програми. За описом кожної з підсхем RDM міст генерує екранну форму JAM;

зворотний режим (JAM-> Silverrun-RDM) призначений для перенесення модифікацій об'єктів CASE-словника в реляційну модель Silverrun-RDM.

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

Групова робота

Ядро JAM має вбудований інтерфейс до засобів конфігураційного управління (PVCS на платформі Windows і SCCS на платформі UNIX). Під управлінням цих систем передаються бібліотеки екранів і / або репозиторії. За відсутності таких систем JAM самостійно реалізує частину функцій підтримки групової розробки.

Використання PVCS (див. підрозділ 3.6) є кращим у порівнянні з SCCS, оскільки дозволяє організувати єдиний архів модулів проекту для всіх платформ. Так як JAM на платформі UNIX не має прямого інтерфейсу до архівів PVCS, то вибірка модулів з архіву і повернення їх в архів виробляються з використанням PVCS Version Manager. На платформі MS-Windows JAM має вбудований інтерфейс до PVCS і дії за вибіркою / поверненню виробляються безпосередньо з середовища JAM.

Середовище функціонування

JAM, як середовище розробки, і додатки, побудовані з його використанням, не є ресурсномісткими системами. Наприклад, на платформі MS-Windows достатньо мати 8MB оперативної пам'яті і 50 MB дискового простору для середовища розробки. На UNIX-платформах вимоги до апаратури визначаються самою операційною системою. 3.2. Vantage Team Builder (Westmount I-CASE) + Uniface 3.2.1. Vantage Team Builder (Westmount I-CASE)

Vantage Team Builder [14] представляє собою інтегрований програмний продукт, орієнтований на реалізацію каскадної моделі ЖЦ ПЗ і підтримку повного ЖЦ ПЗ.

Структура та функції

Vantage Team Builder забезпечує виконання наступних функцій:

проектування діаграм потоків даних, "сутність-зв'язок", структур даних, структурних схем програм та послідовностей екранних форм;

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

генерація коду програм мовою 4GL цільової СУБД з повним забезпеченням програмного середовища і генерація SQL-коду для створення таблиць БД, індексів, обмежень цілісності і збережених процедур;

програмування на мові C з вбудованим SQL;

управління версіями і конфігурацією проекту;

багатокористувацький доступ до сховища проекту;

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

експорт та імпорт даних проекту у форматі CDIF (CASE Data Interchange Format).

Vantage Team Builder поставляється в різних конфігураціях в залежності від використовуваних СУБД (ORACLE, Informix, Sybase або Ingres) або засобів розробки додатків (Uniface). Конфігурація Vantage Team Builder for Uniface відрізняється від інших деяким ступенем орієнтації на спіральну модель ЖЦ ПЗ за рахунок можливостей швидкого прототипування, що надаються Uniface. Для опису проекту ІС використовується досить великий набір діаграм, конкретні варіанти якого для найбільш поширених конфігурацій наведені нижче у таблиці.

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

При побудові DFD забезпечується контроль відповідності діаграм різних рівнів декомпозиції. Контроль за правильністю верхнього рівня DFD здійснюється за допомогою матриці списків подій (ELM). Для контролю за декомпозицією складових потоків даних використовується кілька варіантів їх опису: у вигляді діаграм структур даних (DSD) або в нотації БНФ (форма Бекуса-Наура).

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

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

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

Для підготовки проектної документації можуть використовуватися видавничі системи FrameMaker, Interleaf або Word Perfect. Структура і склад проектної документації можуть бути налаштовані у відповідності з заданими стандартами. Налаштування виконується без зміни проектних рішень.

При розробці досить великої ІС вся система в цілому відповідає одному проекту як категорії Vantage Team Builder. Проект може бути декомпозирована на ряд систем, кожна з яких відповідає деякою відносно автономної підсистеми ІС і розробляється незалежно від інших. У подальшому системи проекту можуть бути інтегровані.

Процес проектування ІС з використанням Vantage Team Builder реалізується у вигляді 4-х послідовних фаз (стадій) - аналізу, архітектури, проектування і реалізації, при цьому закінчені результати кожної стадії повністю або частково переносяться (імпортуються) в наступну фазу. Усі діаграми, крім ERD, перетворюються на інший тип або змінюють вигляд відповідно до особливостей поточної фази. Так, DFD перетворюються у фазі архітектури в SAD, DSD - в DTD. Після завершення імпорту логічний зв'язок з попередньою фазою розривається, тобто в діаграми можуть вноситися всі необхідні зміни.

Взаємодія з іншими засобами

Конфігурація Vantage Team Builder for Uniface забезпечує спільне використання двох систем у рамках єдиної технологічної середовища проектування, при цьому схеми БД (SQL-моделі) переносяться в репозиторій Uniface, і, навпаки, прикладні моделі, сформовані засобами Uniface, можуть бути перенесені в репозиторій Vantage Team Builder. Можливі неузгодженості між репозиторіями двох систем усуваються за допомогою спеціальної утиліти. Розробка екранних форм у середовищі Uniface виконується на базі діаграм послідовностей форм (FSD) після імпорту SQL-моделі. Технологія розробки ІС на базі даної конфігурації показана на малюнку 3.1.

Структура сховища (зберігається безпосередньо в цільової СУБД) і інтерфейси Vantage Team Builder є відкритими, що в принципі дозволяє інтеграцію з будь-якими іншими засобами.

Середовище функціонування

Vantage Team Builder функціонує на всіх основних UNIX-платформах (Solaris, SCO UNIX, AIX, HP-UX) і VMS.

Vantage Team Builder можна використовувати в конфігурації "клієнт-сервер", при цьому база проектних даних може розташовуватися на сервері, а робочі місця розробників можуть бути клієнтами.

Рис. 3.1. Взаємодія Vantage Team Builder і Uniface 3.2.2. Uniface

Uniface 6.1 [15] - продукт фірми Compuware (США) - являє собою середовище розробки великомасштабних додатків в архітектурі "клієнт-сервер" і має наступну компонентну архітектуру:

Application Objects Repository (репозиторій об'єктів додатків) містить метадані, автоматично використовуються усіма іншими компонентами протягом життєвого циклу ІС (прикладні моделі, описи даних, бізнес-правил, екранних форм, глобальних об'єктів і шаблонів). Сховище може зберігатися в будь-якій з баз даних, підтримуваних Uniface;

Application Model Manager підтримує прикладні моделі (ER моделі), кожна з яких представляє собою підмножину загальної схеми БД з точки зору даного продукту, і включає відповідний графічний редактор;

Rapid Application Builder - засіб швидкого створення екранних форм і звітів на базі об'єктів прикладної моделі. Воно включає графічний редактор форм, кошти прототипування, налагодження, тестування і документування. Реалізовано інтерфейс з різноманітними типами віконних елементів управління (Open Widget Interface) для існуючих графічних інтерфейсів - MS Windows (включаючи VBX), Motif, OS / 2. Універсальний інтерфейс подання (Universal Presentation Interface) дозволяє використовувати одну й ту ж версію програми в середовищі різних графічних інтерфейсів без зміни програмного коду;

Developer Services (служби розробника) - використовуються для підтримки великих проектів і реалізують контроль версій (Uniface Version Control System), права доступу (розмежування повноважень), глобальні модифікації і т.д. Це забезпечує розробників засобами паралельного проектування, вхідного і вихідного контролю, пошуку, перегляду, підтримки і видачі звітів за даними системи контролю версій;

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

Personal Series (персональні засоби) - використовуються для створення складних запитів і звітів у графічній формі (Personal Query і Personal Access - PQ / PA), а також для перенесення даних в такі системи, як WinWord і Excel;

Distributed Computing Manager - засіб інтеграції з менеджерами транзакцій Tuxedo, Encina, CICS, OSF DCE.

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

До складу компонент Uniface 7 входять:

Uniface Application Server - сервер додатків для розподілених систем;

WebEnabler - серверне ПЗ для експлуатації додатків в Internet і Intrаnet;

Name Server - серверне ПЗ, що забезпечує використання розподілених прикладних ресурсів;

PolyServer - засіб доступу до даних та інтеграції різних систем.

У список підтримуваних СУБД входять DB2, VSAM і IMS; PolyServer забезпечує також взаємодія з ОС MVS.

Середовище функціонування Uniface - всі основні UNIX - платформи і MS Windows. 3.3. Designer/2000 + Developer/2000

CASE-засіб Designer/2000 2.0 фірми ORACLE [23] є інтегрованим CASE-засобом, що забезпечує в сукупності із засобами розробки додатків Developer/2000 підтримку повного ЖЦ ПЗ для систем, що використовують СУБД ORACLE.

Структура та функції

Designer/2000 являє собою сімейство методологій і підтримуючих їх програмних продуктів. Базова методологія Designer/2000 (CASE * Method) - структурна методологія проектування систем, повністю охоплює всі етапи життєвого циклу ІС [8,9]. Відповідно до цієї методологією на етапі планування визначаються цілі створення системи, пріоритети і обмеження, розробляється системна архітектура і план розробки ІС. У процесі аналізу будуються модель інформаційних потреб (діаграма "сутність-зв'язок"), діаграма функціональної ієрархії (на основі функціональної декомпозиції ІС), матриця перехресних посилань і діаграма потоків даних.

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

На етапі реалізації створюється БД, будуються прикладні системи, проводиться їх тестування, перевірка якості та відповідності вимогам користувачів. Створюється системна документація, матеріали для навчання і керівництва користувачів. На етапах експлуатації та супроводу аналізуються продуктивність і цілісність системи, виконується підтримка і, при необхідності, модифікація ІС;

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

Repository Administrator - засоби управління репозиторієм (створення і видалення програм, управління доступом до даних з боку різних користувачів, експорт та імпорт даних);

Repository Object Navigator - засоби доступу до сховища, що забезпечують багатовіконний об'єктно-орієнтований інтерфейс доступу до всіх елементів репозиторію;

Process Modeller - засіб аналізу і моделювання ділової діяльності, що грунтується на концепціях реінжинірингу бізнес-процесів (BPR - Business Process Reengineering) та глобальної системи управління якістю (TQM - Total Quality Management);

Systems Modeller - набір засобів побудови функціональних та інформаційних моделей проектованої ІС, що включає кошти для побудови діаграм "сутність-зв'язок" (Entity-Relationship Diagrammer), діаграм функціональних ієрархій (Function Hierarchy Diagrammer), діаграм потоків даних (Data Flow Diagrammer) та засіб аналізу і модифікації зв'язків об'єктів репозиторія різних типів (Matrix Diagrammer);

Systems Designer - набір засобів проектування ІС, що включає засіб побудови структури реляційної бази даних (Data Diagrammer), а також засоби побудови діаграм, що відображають взаємодію з даними, ієрархію, структуру і логіку додатків, реалізовану збереженими процедурами на мові PL / SQL (Module Data Diagrammer , Module Structure Diagrammer і Module Logic Navigator);

Server Generator - генератор описів об'єктів БД ORACLE (таблиць, індексів, ключів, послідовностей і т.д.). Крім продуктів ORACLE, генерація і реінжиніринг БД може виконуватися для СУБД Informix, DB / 2, Microsoft SQL Server, Sybase, а також для стандарту ANSI SQL DDL і баз даних, доступ до яких реалізується за допомогою ODBC;

Forms Generator (генератор додатків для ORACLE Forms). Генеруються додатки включають в себе різні екранні форми, засоби контролю даних, перевірки обмежень цілісності і автоматичні підказки. Подальша робота з додатком виконується в середовищі Developer/2000;

Repository Reports - генератор стандартних звітів, інтегрований з ORACLE Reports і дозволяє русифікувати звіти, а також змінювати структурне представлення інформації.

Репозиторій Designer/2000 представляє собою сховище всіх проектних даних і може працювати в многопользовательском режимі, забезпечуючи паралельне оновлення інформації кількома розробниками. У процесі проектування автоматично підтримуються перехресні посилання між об'єктами словника і можуть генеруватися більше 70 стандартних звітів про модельованої предметної області. Фізична середовище зберігання репозиторію - база даних ORACLE.

Генерація додатків, крім продуктів ORACLE, виконується також для Visual Basic.

Взаємодія з іншими засобами

Designer/2000 можна інтегрувати з іншими засобами, використовуючи відкритий інтерфейс додатків API (Application Programming Interface). Крім того, можна використовувати засіб ORACLE CASE Exchange для експорту / імпорту об'єктів репозиторія з метою обміну інформацією з іншими CASE-засобами.

Developer/2000 забезпечує розробку переносимих програм, які працюють в графічному середовищі Windows, Macintosh або Motif. У середовищі Windows інтеграція додатків Developer/2000 з іншими засобами реалізується через механізм OLE і керуючі елементи VBX. Взаємодія додатків з іншими СУБД (DB / 2, DB2/400, Rdb) реалізується за допомогою засобів ORACLE Client Adapter для ODBC, ORACLE Open Gateway і API.

Середовище функціонування

Середовище функціонування Designer/2000 і Developer/2000 - Windows 3.x, Windows 95, Windows NT. 3.4. Локальні засоби (ERwin, BPwin, S-Designor, CASE.Аналітік)

ERwin - засіб концептуального моделювання БД [24], що використовує методологію IDEF1X (див. підрозділ 2.5). ERwin реалізує проектування схеми БД, генерацію її опису мовою цільової СУБД (ORACLE, Informix, Ingres, Sybase, DB / 2, Microsoft SQL Server, Progress та ін) і реінжиніринг існуючої БД. ERwin випускається в декількох різних конфігураціях, орієнтованих на найбільш поширені засоби розробки додатків 4GL. Версія ERwin / OPEN повністю сумісна із засобами розробки додатків PowerBuilder і SQLWindows і дозволяє експортувати опис спроектованої БД безпосередньо в репозиторії даних коштів.

Для ряду засобів розробки додатків (PowerBuilder, SQLWindows, Delphi, Visual Basic) виконується генерація форм і прототипу.

Мережева версія Erwin ModelMart забезпечує узгоджене проектування БД і додатків у рамках робочої групи.

BPwin - засіб функціонального моделювання, реалізує методологію IDEF0 (див. підрозділ 2.2).

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

S-Designor 4.2 являє собою CASE-засіб для проектування реляційних баз даних [25]. За своїми функціональними можливостями і вартістю він близький до CASE-засобу ERwin, відрізняючись зовні використовуваної на діаграмах нотацією. S-Designor реалізує стандартну методологію моделювання даних і генерує опис БД для таких СУБД, як ORACLE, Informix, Ingres, Sybase, DB / 2, Microsoft SQL Server і ін Для існуючих систем виконується реінжиніринг БД. / P>

S-Designor сумісний з низкою засобів розробки додатків (PowerBuilder, Uniface, TeamWindows тощо) і дозволяє експортувати опис БД в репозиторії даних коштів. Для PowerBuilder виконується також пряма генерація шаблонів додатків.

CASE.Аналітік 1.1 [3] є практично єдиним в даний час конкурентоспроможним вітчизняним CASE-засобом функціонального моделювання та реалізує побудова діаграм потоків даних відповідно до методології, описаної в підрозділі 2.3. Його основні функції:

побудова та редагування DFD;

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

отримання різноманітних звітів по проекту;

генерація макетів документів відповідно до вимог ГОСТ 19.ХХХ і 34.ХХХ.

Середовище функціонування: процесор - 386 і вище, основна пам'ять - 4 Мб, дискова пам'ять - 5 Мб, MS Windows 3.x або Windows 95.

Орієнтовна вартість:

однокористувацька версія - 605 $;

багатокористувацька версія (одне робоче місце) - 535 $.

База даних проекту реалізована у форматі СУБД Paradox і є відкритою для доступу.

За допомогою окремого програмного продукту (Catherine) виконується обмін даними з CASE-засобом ERwin. При цьому з проекту, виконаного в CASE.Аналітіке, експортується опис структур даних і накопичувачів даних, яке за певними правилами формує опис сутностей та їх властивостей. 3.5. Об'єктно-орієнтовані CASE-засоби (Rational Rose)

Rational Rose - CASE-засіб фірми Rational Software Corporation (США) - призначено для автоматизації етапів аналізу і проектування ПЗ, а також для генерації кодів на різних мовах і випуску проектної документації [21]. Rational Rose використовує синтез-методологію об'єктно-орієнтованого аналізу і проектування, засновану на підходах трьох провідних фахівців у цій галузі: Буча, Рамбо і Джекобсона. Розроблена ними універсальна нотація для моделювання об'єктів (UML - Unified Modeling Language) претендує на роль стандарту в області об'єктно-орієнтованого аналізу і проектування. Конкретний варіант Rational Rose визначається мовою, на якому генеруються коди програм (C + +, Smalltalk, PowerBuilder, Ada, SQLWindows і ObjectPro). Основний варіант - Rational Rose / C + + - дозволяє розробляти проектну документацію у вигляді діаграм і специфікацій, а також генерувати програмні коди на С + +. Крім того, Rational Rose містить засоби реінжинірингу програм, що забезпечують повторне використання програмних компонент в нових проектах.

Структура та функції

В основі роботи Rational Rose лежить побудова різного роду діаграм і специфікацій, що визначають логічну й фізичну структури моделі, її статичні і динамічні аспекти. У їх число входять діаграми класів, станів, сценаріїв, модулів, процесів [21].

У складі Rational Rose можна виділити 6 основних структурних компонент: репозиторій, графічний інтерфейс користувача, засоби перегляду проекту (browser), засоби контролю проекту, засоби збору статистики і генератор документів. До них додаються генератор кодів (індивідуальний для кожної мови) і аналізатор для С + +, що забезпечує реінжиніринг - відновлення моделі проекту з вихідних текстів програм.

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

Засоби автоматичної генерації кодів програм на мові С + +, використовуючи інформацію, що міститься в логічній та фізичної моделях проекту, формують файли заголовків і файли описів класів та об'єктів. Створюваний таким чином скелет програми може бути уточнений шляхом прямого програмування на мові С + +. Аналізатор кодів С + + реалізований у вигляді окремого програмного модуля. Його призначення полягає в тому, щоб створювати модулі проектів у формі Rational Rose на основі інформації, що міститься в визначених користувачем вихідних текстах на С + +. У процесі роботи аналізатор здійснює контроль правильності вихідних текстів і діагностику помилок. Модель, отримана в результаті його роботи, може цілком або фрагментарно використовуватися в різних проектах. Аналізатор має широкі можливості налаштування по входу і виходу. Наприклад, можна визначити типи вихідних файлів, базовий компілятор, задати, яка інформація повинна бути включена в формовану модель і які елементи вихідний моделі слід виводити на екран. Таким чином, Rational Rose / С + + забезпечує можливість повторного використання програмних компонент.

В результаті розробки проекту з допомогою CASE-засоби Rational Rose формуються наступні документи:

діаграми класів;

діаграми станів;

діаграми сценаріїв;

діаграми модулів;

діаграми процесів;

специфікації класів, об'єктів, атрибутів і операцій

заготівлі текстів програм;

модель розробляється програмної системи.

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

Тексти програм є заготовками для подальшої роботи програмістів. Вони формуються в робочому каталозі в вигляді файлів типів. H (заголовки, що містять описи класів) і. Cpp (заготівлі програм для методів). Система включає в програмні файли власні коментарі, які починаються з послідовності символів //##. Склад інформації, що включається в програмні файли, визначається або за замовчуванням, або за бажанням користувача. Надалі ці вихідні тексти розвиваються програмістами на повноцінні програми.

Взаємодія з іншими засобами і організація групової роботи

Rational Rose інтегрується із засобом PVCS для організації групової роботи і управління проектом та із засобом SoDA - для документування проектів. Інтеграція Rational Rose і SoDA забезпечується засобами SoDA.

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

Для керованої подмодели передбачено операції:

завантаження подмодели в пам'ять;

вивантаження подмодели з пам'яті;

збереження подмодели на диску у вигляді окремого файлу;

установка захисту від модифікації;

заміна подмодели в пам'яті на нову.

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

Середовище функціонування

Rational Rose функціонує на різних платформах: IBM PC (в середовищі Windows), Sun SPARC stations (UNIX, Solaris, SunOS), Hewlett-Packard (HP UX), IBM RS/6000 (AIX).

Для роботи системи необхідно виконання наступних вимог:

Платформа Windows - процесор 80386SX або вище (рекомендується 80486), память8Mб (рекомендується 12Mб), простір на диску 8Mб + 1-3Mб для однієї моделі.

Платформа UNIX - пам'ять 32 + (16 * число користувачів) Mб, простір на диску 30Mб + 20 при інсталяції + 1-3Mб для однієї моделі.

Працює за версіями забезпечується на рівні моделей. 3.6. Допоміжні засоби підтримки життєвого циклу ПЗ 3.6.1. Засоби конфігураційного управління

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

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

Найбільш поширеним засобом КУ є PVCS фірми Intersolv (США), що включає ряд самостійних продуктів: PVCS Version Manager, PVCS Tracker, PVCS Configuration Builder і PVCS Notify.

PVCS Version Manager [18] призначений для управління всіма компонентами проекту та ведення планомірної багатоверсійності і багатоплатформного розробки силами команди розробників в умовах однієї або кількох локальних мереж. Поняття "проект" трактується як сукупність файлів. У процесі роботи над проектом проміжний стан файлів періодично зберігається в архіві проекту, ведуться записи про час збереження, відповідно один одному декількох варіантів різних файлів проекту. Крім цього, фіксуються імена розробників, відповідальних за той чи інший файл, склад файлів проміжних версій проекту та ін Це дозволяє повернутися при необхідності до якого-небудь з попередніх станів файлу (наприклад, при виявленні помилки, яку в даний момент важко виправити).

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

Доступ до архівів PVCS Version Manager можливий не тільки через сам Version Manager, але і з більш ніж 50 інструментальних засобів, у тому числі MS Visual C і MS Visual Basic, Uniface, PowerBuilder, SQL Windows, JAM, Delphi, Paradox та ін

Результатом роботи PVCS Version Manager є створений засобами файлової системи репозиторій, що зберігає в компактній формі всі робочі версії програмного продукту разом з необхідними коментарями та мітками.

PVCS Version Manager функціонує в середовищі MS Windows, Windows 95, Windows NT, OS / 2, SunOS, Solaris, HP-UX, AIX і SCO UNIX і може виконуватися на будь-якому персональному комп'ютері з процесором 80386 або вище, робочих станціях Sun, HP і IBM (RS-6000).

Іншим засобом конфігураційного управління є PVCS Tracker [19] - спеціалізована надбудова над офісної електронною поштою, призначена для обробки повідомлень про помилки в продукті, доставці їх виконавцям та контролю за виконанням. Інтеграція з PVCS Version Manager дає можливість пов'язувати з повідомленнями ті чи інші компоненти проекту. Звітні можливості PVCS Tracker включають безліч різновидів графіків і діаграм, що відображають стан проекту та процесу його налагодження, зрізи по різних компонентах проекту, розробникам і тестувальникам. З їх допомогою можна наочно показати поточний стан роботи над проектом та її часові тенденції.

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

користувачі (Submitters) - мають обмежені права на внесення зауважень та повідомлень про помилки в базу даних PVCS Tracker;

розробники (Development Engineers) - мають право виробляти основні операції з вимогами і зауваженнями в базі даних PVCS Tracker. Якщо розробники діляться на підгрупи, то для кожної підгрупи можуть бути задані окремі списки прав доступу;

тестувальники (Quality Engineers) - мають право виробляти основні операції з вимогами та зауваженнями;

супровід (Support Engineers) - мають право вносити будь-які зауваження, вимоги та рекомендації до бази даних, але не мають прав з розподілу робіт і зміни їх пріоритетності та термінів виконання;

керівники (Managers) - мають право розподіляти роботи між виконавцями і приймати рішення про їх належному виконанні. Керівникам різних груп можуть задані різні права доступу до бази даних PVCS Tracker.

На додаток до цих п'яти наперед визначеним групам, існує група адміністратора бази даних і 11 додаткових груп, які можуть бути налаштовані у відповідності зі специфічними посадовими обов'язками співробітників, що використовують PVCS Tracker.

Вимога або зауваження надходить в PVCS Tracker проходить чотири етапи обробки:

реєстрація - внесення зауваження до бази даних;

розподіл - призначення відповідального виконавця і термінів виконання;

виконання - усунення зауваження, яке в свою чергу може викликати додаткові зауваження чи вимоги на додаткові роботи;

приймання - приймання робіт і зняття їх з контролю або направлення на доопрацювання.

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

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

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

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

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

поліпшується чи якість програмного продукту і яка динаміка цього процесу;

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

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

PVCS Tracker призначений для використання в робочих групах, об'єднаних в загальну мережу. У цьому випадку центральна база або проект PVCS Tracker знаходиться на загальнодоступному сервері мережі, доступ до якого реалізується за допомогою ODBC-драйверів, що входять до складу PVCS Tracker. Головною особливістю PVCS Tracker в порівнянні зі звичайним додатком СУБД є його здатність автоматично повідомляти користувача про надходження цікавить його або відноситься до його компетенції інформації та гнучка система розподілу повноважень всередині робочої групи. При необхідності PVCS Tracker може використовувати для повідомлення віддалених членів групи електронну пошту.

PVCS Tracker підтримує групову роботу в локальних мережах і взаємодіє з СУБД dBase, ORACLE, SQL Server і SYBASE допомогою ODBC.

PVCS Tracker може бути інтегрований з будь-якою системою електронної пошти, що підтримує стандарти VIM, MAPI або SMTP.

PVCS Version Manager і PVCS Tracker оточені допоміжними компонентами: PVCS Configuration Builder і PVCS Notify.

PVCS Configuration Builder призначений для складання остаточного продукту з компонент проекту. PVCS Configuration Builder дозволяє описувати процес збірки як на стандартному мовою MAKE, так і на власному внутрішньому мовою, що має істотно більші можливості. PVCS Configuration Builder дозволяє здійснювати збірку програмного продукту на підставі файлів, що зберігаються в репозиторії PVCS Version Manager.

Звичайна процедура збирання програмного продукту за допомогою PVCS Configuration Builder складається з трьох кроків:

будується файл залежностей між вихідними модулями;

в отриманий файл вносяться зміни з метою його налаштування і оптимізації;

здійснюється складання програмного продукту з вихідних модулів.

Результатом роботи PVCS Configuration Builder є спеціальний файл, що описує оптимальний алгоритм збирання програмного продукту, побудований на основі аналізу дерева залежностей між вихідними модулями.

PVCS Notify забезпечує автоматичну розсилку повідомлень про помилки з бази даних пакету PVCS Tracker по робочих станцій призначення. При цьому використовується офісна система електронної пошти cc: Mail або Microsoft Mail. PVCS Notify розширює можливості PVCS Tracker і використовується тільки разом з ним.

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

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

Результатом роботи PVCS Notify є оформлені відповідно до одного зі стандартів поштові повідомлення, готові для розсилки за допомогою системи електронної пошти. 3.6.2. Засоби документування

Для створення документації в процесі розробки ІС використовуються різноманітні засоби формування звітів, а також компоненти видавничих систем. Зазвичай кошти документування вбудовані в конкретні CASE-засоби. Винятком є ​​деякі пакети, надають додатковий сервіс при документуванні. З них найбільш активно використовується SoDA (Software Document Аutomation).

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

SoDA не залежить від застосовуваних інструментальних засобів. Зв'язок з додатками здійснюється через стандартний програмний інтерфейс API. Перехід на нові інструментальні засоби не тягне за собою додаткових витрат з документування проекту.

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

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

SoDA реалізована на базі видавничої системи FrameBuilder і надає повний набір засобів для редагування та верстки випускається документації. Різні версії документації можуть бути для наочності відзначені своїми відмітними ознаками. У системі створюються таблиці вимог до проекту, за якими можна простежити, як реалізуються ці вимоги. Різні види документації, які супроводжують різні етапи ЖЦ, пов'язані між собою, і можна простежити стан проекту від первинних вимог до аналізу, проектування, кодування і тестування програмного продукту.

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

Середовище функціонування SoDA - ОС типу UNIX на робочих станціях Sun SPARCstation, IBM RISC System/6000 або Hewlett Packard HP 9000 700/800.

SoDA потребує щонайменше 32 MB оперативної пам'яті, 100-300 MB для установки і 64 MB робочого простору на диску. 3.6.3. Засоби тестування

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

Одне з найбільш розвинених засобів тестування QA (нова назва - Quality Works) [20] представляє собою інтегровану, багатоплатформенна середовище для розробки автоматизованих тестів будь-якого рівня, включаючи тести регресії для додатків з графічним інтерфейсом користувача.

QA дозволяє починати тестування на будь-якій фазі ЖЦ, планувати і керувати процесом тестування, відображати зміни в додатку і повторно використовувати тести для більш ніж 25 різних платформ.

Основними компонентами QA є:

QA Partner - середовище для розробки, компіляції та виконання тестів;

QA Planner - модуль для розробки планів тестування та обробки результатів. Для створення і виконання тестів в процесі роботи QA Planner викликається QA Partner;

Agent - модуль, що підтримує роботу в мережі.

Процес тестування складається з наступних етапів:

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

зв'язування плану з тестами;

помітка і виконання тестів;

отримання звітів про тестування та управління результатами.

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

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

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

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

Комплекс QA займає на жорсткому диску не більше 21МВ. Підтримувані платформи: Windows 3.x, Windows 95, Windows NT, OS / 2, Macintosh, VMS, HP-UX, AIX, Solaris. 3.7. Приклади комплексів CASE-засобів

На закінчення наведемо приклади комплексів CASE-засобів забезпечують підтримку повного ЖЦ ПЗ. Тут хотілося б ще раз відзначити недоцільність порівняння окремо взятих CASE-засобів, оскільки жодна з них не вирішує в цілому всі проблеми створення та супроводження ПЗ. Це підтверджується також повним набором критеріїв оцінки та вибору, які зачіпають всі етапи ЖЦ ПЗ. Порівнюватися можуть комплекси методологічно і технологічно узгоджених інструментальних засобів, що підтримують повний ЖЦ ПЗ і забезпечені необхідною технічною і методичною підтримкою з боку фірм-постачальників. На думку автора, на сьогоднішній день найбільш розвиненим з усіх поставляються в Росії комплексів такого роду є комплекс технологій та інструментальних засобів створення ІС, заснований на методології і технології DATARUN. До складу комплексу входять такі інструментальні засоби:

CASE-засіб Silverrun;

засіб розробки додатків JAM;

міст Silverrun-RDM JAM;

комплекс засобів тестування QA;

менеджер транзакцій Tuxedo;

комплекс засобів планування та управління проектом SE Companion;

комплекс засобів конфігураційного управління PVCS;

об'єктно-орієнтоване CASE-засіб Rational Rose;

засіб документування SoDA.

Прикладами інших подібних комплексів є:

Vantage Team Builder for Uniface + Uniface (фірми "DataX / Florin" і "ЛАНІТ");

комплекс засобів, що поставляються та використовуються фірмою "ФОРС":

CASE-засоби Designer/2000 (основне), ERwin, Bpwin і Oowin (альтернативні);

засоби розробки додатків Developer/2000, ORACLE Power Objects (основні) і Usoft Developer (альтернативне);