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

.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. Після створення моделі бізнес-процесів інформація зберігається в репозиторії проекту.

На основі структур первинних даних в модулі 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

.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).

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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