Порівняння Silverrun та CA ERwin Data Modeler на прикладі роботи інтернет-магазину

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

Вступ

Темою курсової роботи CASE-засоби. Порівняння Silverrun та CA ERwin Data Modeler на прикладі роботи інтернет-магазину. Основним завданням є забезпечення вибору найоптимальнішого, найзручнішого та найшвидшого CASE-засобу для виконання завдання.

Для досягнення цієї мети необхідно:

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

- реалізувати вирішення завдання за допомогою SILVERRUN;

- реалізувати вирішення завдання за допомогою CA ERwin Data Modeler;

- порівняти CA ERwin Data Modeler та SILVERRUN.

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

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

1. Загальна характеристика та класифікація CASE-засобів

1.1 Класифікація і характеристика CASE-засобів

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

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

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

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

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

· інтеграція окремих компонент CASE-засобів, забезпечує керованість процесом розробки ІС;

· використання спеціальним чином організованого сховища проектних метаданих (репозиторію).

Інтегрований CASE-засіб (чи комплекс засобів, підтримують повний ЖЦ ПЗ) містить такі компоненти:

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

· графічні засоби аналізу і проектування, що забезпечують створення і редагування ієрархічно пов'язаних діаграм (DFD, ERD та інших.), Утворюють моделі ІС;

· засоби розробки додатків, включаючи мови 4GL і генератори кодів;

· кошти конфігураційного управління;

· кошти документування;

· засоби тестування;

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

· кошти реінжинірингу.

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

· застосовуваним методологіям і моделям систем і БД;

· ступеня інтегрованості з СКБД;

· доступним платформам.

Класифікація за типами переважно збігається з компонентним складом CASE-засобів і включає наступні основні типи:

· засоби аналізу (Upper CASE), призначені для побудови та аналізу моделей предметної області (Design / IDEF (Meta Software), BPwin (Logic Works));

· кошти аналізу та проектування (Middle CASE), підтримують найбільш поширені методології проектування й які використовуються для створення проектних специфікацій (Vantage Team Builder (Cayenne), конструктор / 2000 (ORACLE), SILVERRUN (CSA), PRO-IV (McDonnell Douglas), CASE Аналітики (МакроПроджект)). Виходом таких засобів є специфікації компонентів і інтерфейсів системи, архітектури системи, алгоритмів і структур даних;

· засоби проектування баз даних, що забезпечують моделювання даних і генерацію схем баз даних (як правило, на мові SQL) для найбільш поширених СУБД. До них відносяться ERwin (Logic Works), S-Designor (СДП) і База даних Дизайнер (Oracle). Засоби проектування баз даних є також в складі CASE-засобів Vantage Team Builder, конструктор / 2000, SILVERRUN і PRO-IV;

· засоби розробки додатків. До них відносяться засоби 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Розробник / 2000 (ORACLE), Нова ера (Informix), SQL Windows, (Гупта), Delphi (Borland) та ін.) І генератори кодів, що входять до складу Vantage Team Builder PRO-IV і частково - в SILVERRUN;

· кошти реінженірингу, щоб забезпечити аналіз програмних кодів і схем баз даних і формування на їх основі різних моделей і проектних специфікацій. Засоби аналізу схем БД і формування ERD входять до складу команди Vantage Будівельник, PRO-IV SILVERRUN, конструктор / 2000, ERwin і S-Designor. У сфері аналізу програмних кодів найбільшого поширення отримують об'єктно-орієнтовані CASE-засоби, що забезпечують реінжиніринг програм мовою С ++ (Rational Rose (Rational Software), Object Team (Cayenne)).

Допоміжні типи включають:

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

· кошти конфігураційного управління;

· засоби тестування;

· кошти документування.

Сьогодні ринок програмного забезпечення багатий такими найрозвинутішими CASE-засобами:

· Vantage Team Builder;

· Designеr / 2000;

· SILVERRUN;

· ERwin + BPwin;

· S-Designor;

· CASE.Аналітик.

Крім того, на ринку постійно з'являються як нові для вітчизняних користувачів системи (наприклад, CASE / 4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так і нові версії і модифікації перерахованих систем.

1.2 Технологія впровадження CASE-засобів

Наведена в даному розділі технологія базується в основному на стандартах IEEE (IEEE - Institute of Electrical and Electronics Engineers - Інститут інженерів з електротехніки та електроніки). Термін "впровадження" використовується в широкому сенсі і включає всі дії від оцінки первинних потреб до повномасштабного використання CASE-засобів в різних підрозділах організації-користувача. Процес впровадження CASE-засобів складається з наступних етапів:

· визначення потреб у CASE-засобах;

· оцінка та вибір CASE-засобів;

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

· практичне впровадження CASE-засобів.

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

Рис. 1.1 - Визначення потреби в CASE-засобах

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

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

1.3 Аналіз ринку CASE-засобів

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

1.4 Визначення критеріїв успішного впровадження

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

Як правило, більшість організацій здійснює впровадження CASE-засобів для того, щоб підвищити продуктивність процесів розробки і супроводу ПЗ, а також якість результатів розробки. Однак, ряд організацій не займаються і не займалися раніше збором кількісних даних за вказаними параметрами. Відсутність таких даних ускладнює кількісну оцінку впливу, що чиниться впровадженням CASE-засобів. У цьому випадку рекомендується розробка відповідних метрик. Інформація про такі метриках приведена в стандартах IEEE Std 1045-1992 (IEEE Standard for Software Productivity Metrics) і IEEE Std 1061-1992 (IEEE Standard for a Software Quality Metrics Methodology).

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

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

· узгодженість проектних результатів;

· точність вартісних і планових оцінок;

· мінливість зовнішніх вимог;

· дотримання стандартів організації;

· ступінь повторного використання існуючих компонентів ПО;

· обсяг і види необхідного навчання;

· типи і моменти виявлення проектних помилок;

· обчислювальні ресурси, використовувані CASE-засобами.

1.5 Розробка стратегії впровадження CASE-засобів

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

· організаційні потреби;

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

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

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

· вплив, який чиниться на інші підрозділи організації;

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

· основні фактори ризику;

· орієнтовний рівень витрат і джерела фінансування процесу впровадження CASE-засобів;

· ключовий персонал та інші ресурси.

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

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

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

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

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

Існує кілька підходів до розробки стратегії впровадження CASE-засобів. Відносні переваги того чи іншого підходу перед іншими повинні розглядатися в контексті специфіки конкретної організації. Особливе значення при цьому надається персоналу організації і процесу розробки ПЗ.

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

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

Недоліки даного підходу полягають в наступному:

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

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

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

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

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

Переваги даного підходу полягають в наступному:

· невелика автоматизація може бути виконана при мінімальних витратах;

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

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

Недоліки даного підходу полягають в наступному:

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

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

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

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

1.6 Оцінка і вибір CASE-засобів

1.6.1 Загальні відомості

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

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

· оцінка декількох CASE-засобів і вибір одного або більше з них;

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

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

Рис.1.2 - Модель процесу оцінки і вибору

Як видно з рисунка, вхідною інформацією для процесу оцінки є:

· визначення користувальницьких потреб;

· цілі та обмеження проекту;

· дані про доступні CASE-засобах;

· список критеріїв, які використовуються в процесі оцінки.

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

Елементи процесу включають:

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

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

· критерії, що визначають набір параметрів, відповідно до яких проводиться оцінка і прийняття рішення про вибір;

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

· рекомендований рішення (зазвичай або рішення про вибір, або подальша оцінка).

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

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

Визначення переліку критеріїв засноване на користувацьких вимогах і включає:

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

· визначення додаткових критеріїв;

· визначення області використання кожного критерію (оцінка, вибір або обидва процесу);

· визначення однієї або більше метрик для кожного критерію оцінки;

· призначення ваги кожним критерієм при виборі.

1.6.2 Виконання пілотного проекту

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

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

· підтвердити достовірність результатів оцінки та вибору;

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

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

· придбати власний досвід використання CASE-засоби.

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

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

Первісне використання нової CASE-технології у пілотному проекті повинне ретельно плануватися і контролюватися.

1.6.3 Визначення характеристик пілотного проекту

Пілотний проект повинен володіти наступними характеристиками:

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

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

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

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

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

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

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

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

2. Розгляд CASE-засобу Silverrun

2.1 Silverrun

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

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

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

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 різних рівнів декомпозиції). Слід, однак, відзначити, що цей недолік може мати суттєве значення тільки у випадку використання каскадної моделі ЖЦ ПЗ.

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

Для автоматичної генерації схем баз даних у 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-драйвери. Для доступу до даних сховища з найбільш поширених систем управління базами даних забезпечена можливість зберігати всю проектну інформацію безпосередньо у форматі цих СУБД.

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

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

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

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

2.5 Методологія DATARUN

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

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

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

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

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

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

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

Методологія DATARUN опирається на дві моделі або на два подання:

· модель організації;

· модель ІС.

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

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

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

Підхід DATARUN переслідує дві мети:

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

· спроектувати ІВ виходячи моделі даних.

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

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

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

Рис. 2.1 - Моделі, що створюються за допомогою підходу DATARUN

Моделі, що створюються за допомогою підходу DATARUN:

· BPM (Business Process Model) - модель бізнес-процесів.

· PDS (Primary Data Structure) - структура первинних даних.

· CDM (Conceptual Data Model) - концептуальна модель даних.

· SPM (System Process Model) - модель процесів системи.

· ISA (Information System Architecture) - архітектура інформаційної системи.

· ADM (Application Data Model) - модель даних програми.

· IPM (Interface Presentation Model) - модель представлення інтерфейсу.

· ISM (Interface Specification Model) - модель специфікації інтерфейсу.

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

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

На основі структур первинних даних в модулі Silverrun ERX створюється концептуальна модель даних (ER-модель). Від структур первинних даних концептуальна модель відрізняється видаленням надмірності, стандартизацією найменувань понять і нормалізацією. Ці операції в модулі ERX виконуються з допомогою вбудованої експертної системи. Мета концептуальної моделі даних - описати використовувану інформацію без деталей можливої ??реалізації у базі даних, але в добре структурованому нормалізованому вигляді.

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

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

Перед розробкою додатків повинна бути спроектована структура корпоративної бази даних. DATARUN припускає використання бази даних, заснованої на реляційної моделі. Концептуальна модель даних після нормалізації переноситься модуль реляційного моделювання Silverrun RDM з допомогою спеціального мосту ERX-RDM. Перетворення моделі з формату ERX в формат RDM відбувається автоматично без втручання користувача. Після перетворення форматів виходить модель реляційної бази даних. Ця модель деталізується в модулі Silverrun RDM визначенням фізичної реалізації (типів даних СУБД, ключів, індексів, тригерів, обмежень посилальної цілісності). Правила обробки даних можна задавати як безпосередньо на мові програмування СУБД, і у декларативної формі, не прив'язаної до реалізації. Мости Silverrun до реляційних СУБД переводять ці декларативні правила мовою необхідної системи, що знижує трудомісткість програмування процедур серверу бази даних, а також дозволяє з однієї специфікації генерувати програми для різних СУБД.

За допомогою моделі системних процесів детально документується поведінка кожного докладання. У модулі BPM створюється модель системних процесів, визначальна, як реалізуються бізнес-процеси. Ця модель створюється окремо для кожного додатка і тісно пов'язана з моделлю даних програми.

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

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

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

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

3. Розгляд CASE-засобу CA ERwin Data Modeler

3.1 ERwin Data Modeler

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

Рішення CA ERwin Data Modeler допомагає організаціям керувати складною інфраструктурою даних за допомогою наступних основних можливостей:

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

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

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

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

· порівняння моделей і баз даних. Функція Complete Compare автоматизує двонаправлену синхронізацію моделей, скриптів та баз даних, порівнює одне елемент з іншим, відображає всі відмінності і дозволяє виконувати вибіркові оновлення, створюючи при необхідності скрипти ALTER.

· інтеграція та обмін метаданими з іншими засобами. Інтегруйте моделі ERwin з іншими проектами та інструментами, імпортуючи і експортуючи дані з широкого діапазону джерел, у тому числі із засобів бізнес-аналітики, MDM-концентраторів, а також інших інструментів моделювання даних, засобів ETL (Extract, Transform, Load) і UML (Unified Modeling Language).

3.2 Переваги, результати застосування та ключові функції CA ERwin Data Modeler

Основні переваги і результати застосування:

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

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

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

Ключові функції:

· візуалізація складних структур даних;

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

· визначення стандартів для мінімізації надмірності;

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

· порівняння моделей і баз даних;

· інтеграція та обмін метаданими з іншими засобами.

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

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

4. Побудова uml-діаграм для роботи інтернет-магазину

4.1 Проектування роботи інтернет магазину за допомогою UML-діаграм

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

Система повинна забезпечувати можливість виконання наступних функцій:

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

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

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

· отримання відомостей про поточний стан товарів на складі.

Вихідні дані:

· вибрана покупцем модель виробу;

· наявність товару на складі;

· поточні відомості про можливість доставки товару.

На рисунках 4.1 - 4.4 зображено діаграми прецедентів, діяльності, послідовності та кооперацій роботи інтернет магазину. Розглянемо рис. 4.1 на якому зображено діаграму прецедентів.



Рис. 4.1 - Діаграма прецедентів, що відображає процеси, пов'язані з роботою інтернет-магазину

Розглянемо рис. 4.2 на якому зображено діаграму діяльності.

Рис. 4.2 - Діаграма діяльності процесу роботи інтернет-магазину



Рис. 4.3 - Діаграма послідовності процесу роботи інтернет-магазину

На рис. 4.3 та на рис. 4.4 зображено діаграми послідовністі та кооперації, що описують роботу інтернет магазину

Рис. 4.4 - Діаграма кооперації, що відображає процес роботи інтернет-магазину

Результати:

· запис покупця в базу даних;

· оформлений договір про покупку товару;

· оплата товару;

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

· доставка товару.

5. Порівняльна характеристика CA ERwin Data Modeler та Silverrun

5.1 Приклад роботи з програмою Silverrun

Для практичного порівняння роботи у різних CASE-засобах продовжуючи досліджувати тему інтернет магазину даний проект було досліджено у Silverrun та CA ERwin Data Modeler.

Розглянемо рис. 5.1, на якому зображено роботу магазину у програмі Silverrun.

Рис. 5.1 - Робота інтернет магазину зображена у програмі SILVERRUN

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

· заголовку вікна програми;

· головного меню, яке складається з восьми пунктів;

· піктографічного меню, яке знаходиться cправа;

· робочого поля.

Візуально все виглядає досить просто та особисто мені асоціюється з стандартною програмою Paint.

5.2 Приклад роботи з програмою CA ERwin Data Modeler

Тепер розглянемо рис. 5.2, на якому аналогічно зображено роботу магазину, але на цей раз використано програму CA ERwin Data Modeler.

Рис. 5.2 - Робота інтернет магазину зображена у програмі CA ERwin Data Modeler

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

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

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

· присутня Функція Complete Compare автоматизує двонаправлену синхронізацію моделей, скриптів та баз даних, порівнює одне елемент з іншим, відображає всі відмінності і дозволяє виконувати вибіркові оновлення, створюючи при необхідності скрипти ALTER;