Методології проектування ПЗ як програмні продукти. Методологія DATARUN та інструментальне засіб SE Companion
Сучасні методології і реалізують їх технології поставляються в електронному вигляді разом з CASE-засобами і включають бібліотеки процесів, шаблонів, методів, моделей та інших компонент, призначених для побудови ПО того класу систем, на який орієнтована методологія. Електронні методології включають також засоби, які повинні забезпечувати їх адаптацію для конкретних користувачів і розвиток методології за результатами виконання конкретних проектів.
Процес адаптації полягає у видаленні непотрібних процесів, дій ЖЦ та інших компонентів методології, у зміні невідповідних або в додаванні власних процесів і дій, а також методів, моделей, стандартів і керівництв. Налаштування методології може здійснюватися також за наступним аспектам: етапи та операції ЖЦ, учасники проекту, використовувані моделі ЖЦ, підтримувані концепції та ін
Електронні методології та технології (і підтримують їх CASE-засоби) складають ядро комплексу узгоджених інструментальних засобів середовища розробки ІС.
Методологія DATARUNОднією з найбільш поширених в світі електронних методологій є методологія DATARUN [6,26]. Відповідно до методології DATARUN ЖЦ ПО розбивається на стадії, які пов'язуються з результатами виконання основних процесів, визначених стандартом ISO 12207. Кожну стадію крім її результатів має завершувати план робіт на наступну стадію.
Стадія формування вимог і планування включає в себе дії з визначення початкових оцінок обсягу та вартості проекту. Повинні бути сформульовані вимоги та економічне обгрунтування для розробки ІС, функціональні моделі (моделі бізнес-процесів організації) і вихідна концептуальна модель даних, які дають основу для оцінки технічної реалізованості проекту. Основними результатами цій стадії повинні бути моделі діяльності організації (вихідні моделі процесів і даних організації), вимоги до системи, включаючи вимоги по сполученню з існуючими ІС, вихідний бізнес-план.
Стадія концептуального проектування починається з детального аналізу первинних даних та уточнення концептуальної моделі даних, після чого проектується архітектура системи. Архітектура включає в себе поділ концептуальної моделі на доступні для огляду подмодели. Оцінюється можливість використання існуючих ІС і вибирається відповідний метод їх перетворення. Після побудови проекту уточнюється вихідний бізнес-план. Вихідними компонентами цієї стадії є концептуальна модель даних, модель архітектури системи і уточнений бізнес-план.
На стадії специфікації додатків триває процес створення та деталізації проекту. Концептуальна модель даних перетворюється в реляційну модель даних. Визначається структура програми, необхідні інтерфейси програми у вигляді екранів, звітів та пакетних процесів разом з логікою їх виклику. Модель даних уточнюється бізнес-правил і методів для кожної таблиці. У кінці цієї стадії приймається остаточне рішення про спосіб реалізації додатків. За результатами стадії повинен бути побудований проект ІВ, до складу моделі архітектури ІС, даних, функцій, інтерфейсів (із зовнішніми системами і з користувачами), вимог до розроблюваних додатків (моделі даних, інтерфейсів і функцій), вимог до доопрацюванням існуючих ІС, вимог до інтеграції додатків, а також сформований остаточний план створення ІС.
На стадії розробки, інтеграції та тестування повинна бути створена тестова база даних, приватні та комплексні тести. Проводиться розробка, прототипування і тестування баз даних і додатків відповідно до проекту. Відладжуються інтерфейси з існуючими системами. Описується конфігурація поточної версії ПЗ. На основі результатів тестування проводиться оптимізація бази даних та програм. Програми інтегруються в систему, проводиться тестування додатків у складі системи та випробування системи. Основними результатами стадії є готові програми, перевірені в складі системи на комплексних тестах, поточне опис конфігурації ПЗ, скоригована за результатами випробувань версія системи та експлуатаційна документація на систему.
Стадія впровадження включає в себе дії з встановлення і впровадження баз даних і додатків. Основними результатами стадії повинні бути готова до експлуатації і перенесена на програмно-апаратну платформу замовника версія системи, документація супроводу та акт приймальних випробувань за результатами дослідної експлуатації.
Стадії супроводу та розвитку включають процеси та операції, пов'язані з реєстрацією, діагностикою та локалізацією помилок, внесенням змін і тестуванням, проведенням доробок, тиражуванням та розповсюдженням нових версій ПЗ в місця його експлуатації, перенесенням додатків на нову платформу і масштабуванням системи. Стадія розвитку фактично є повторної итерацией стадії розробки.
Методологія DATARUN спирається на дві моделі або на дві вистави:
модель організації; модель ІС.Методологія DATARUN базується на системному підході до опису діяльності організації. Побудова моделей починається з опису процесів, з яких потім витягуються первинні дані (стабільне підмножина даних, які організація повинна використовувати для своєї діяльності). Первинні дані описують продукти або послуги організації, їх операції (транзакції) та спожиті ресурси. До первинних належать дані, які описують зовнішні і внутрішні суті, такі як службовці, клієнти або агентства, а також дані, отримані в результаті прийняття рішень, як наприклад, графіки робіт, ціни на продукти.
Основний принцип DATARUN полягає в тому, що первинні дані, якщо вони належним чином організовані в модель даних, стають основою для проектування архітектури ІС. Архітектура ІВ буде більш стабільною, якщо вона заснована на первинних даних, тісно пов'язаних з основними діловими операціями, визначальними природу бізнесу, а не на традиційній функціональної моделі.
Будь-яка ІС (рисунок 3.1) являє собою набір модулів, виконуваних процесорами і взаємодіючих з базами даних. Бази даних і процесори можуть розташовуватися централізовано або бути розподіленими. Події в системі можуть ініціюватися зовнішніми сутностями, такими як клієнти біля банкоматів або тимчасові події (кінець місяця чи кварталу). Всі транзакції здійснюються через об'єкти або модулі інтерфейсу, які взаємодіють з одного або більше базами даних.
Рис. 3.1. Модель ІС
Підхід DATARUN переслідує дві мети:
визначити стабільну структуру, на основі якої буде будуватися ІВ. Такою структурою є модель даних, отримана з первинних даних, що представляють фундаментальні процеси організації; спроектувати ІС на основі моделі даних.Об'єкти, які формуються на основі моделі даних, є об'єктами бази даних, зазвичай розташовуються на серверах в середовищі клієнт / сервер. Об'єкти інтерфейсу, визначені в архітектурі комп'ютерної системи, зазвичай розміщуються на клієнтської частини. Модель даних, що є основою для специфікації спільно використовуваних об'єктів бази даних і різних об'єктів інтерфейсу, забезпечує сопровождаемость ІС. На малюнку 3.2 представлена послідовність кроків проектування ІС.
На малюнку 3.3 визначено моделі, що створюються в процесі розробки ІС. Для їх створення використовується CASE-засіб Silverrun, описане в підрозділі 5.1. Silverrun забезпечує автоматизацію проведення проектних робіт у відповідності з методологією DATARUN. Надана цими засобами середовище проектування дає можливість керівнику проекту контролювати проведення робіт, відстежувати виконання робіт, вчасно помічати відхилення від графіка. Кожен учасник проекту, підключившись до цього середовища, може з'ясувати зміст і терміни виконання дорученої йому роботи, детально вивчити техніку її виконання в гіпертексті за технологіями, і викликати інструмент (модуль Silverrun) для реального виконання роботи.
Інформаційна система створюється послідовним побудовою ряду моделей, починаючи з моделі бізнес-процесів і закінчуючи моделлю програми, що автоматизує ці процеси.
Рис. 3.2. Послідовність кроків проектування системи
· BPM (B usiness P rocess M odel) - модель бізнес-процесів.
PDS (P rimary D ata S tructure) - структура первинних даних.
CDM (C onceptual D ata M odel) - концептуальна модель даних.
SPM (S ystem P rocess M odel) - модель процесів системи.
ISA (I nformation S ystem A rchitecture) - архітектура інформаційної системи.
ADM (A pplication D ata M odel) - модель даних програми.
IPM (I nterface P resentation M odel) - модель представлення інтерфейсу.
ISM (I nterface S pecification M odel) - модель специфікації інтерфейсу.
Рис. 3.3. Моделі, що створюються за допомогою підходу DATARUN
Створювана ІС повинна грунтуватися на функціях, виконуваних організацією. Тому перша створювана модель - це модель бізнес-процесів, побудова якої здійснюється в модулі 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 дозволяють швидко створювати працюючі прототипи додатків, користувач має можливість побачити працюючий прототип системи на ранніх стадіях проектування.
Після створення подсхем реляційної моделі для додатків проектується детальна структура кожного додатка у вигляді схеми навігації екранів, звітів, процедур пакетної обробки. На цьому кроці ця структура деталізується до вказівки конкретних стовпців і таблиць бази даних, правил їх обробки, виду екранних форм і звітів. Отримана модель детально документує програми та безпосередньо використовується для програмування специфікованих інтерфейсів.
Далі, за допомогою засобів розробки додатків відбувається фізичне створення системи: додатки програмуються і інтегруються в інформаційну систему.
Інструментальне засіб SE CompanionІнструментальне засіб SE Companion [27] є середовищем, в якій реалізований електронний варіант методології DATARUN. Воно дозволяє:
створити гіпертекстове опис методології у вигляді ієрархії опису стадій, етапів і операцій розробки; створити гіпертекстове опис всіх методів і методик реалізації процесів ЖЦ ПЗ; виділити з гіпертекстового опису ієрархію процесів ЖЦ ПЗ для планування та управління процесом створення ПЗ (ієрархію робіт); змінювати гіпертекстові опису ЖЦ і методів так, як це необхідно розробнику, іншими словами, проводити авторизацію методології і відслідковувати ці зміни в ієрархії робіт, призначеної для управління проектом; прив'язати до процесів ЖЦ інструментальні засоби підтримки цих процесів і забезпечити виклик інструментальних засобів з відповідних екранів гіпертекстового довідника; забезпечити перегляд гіпертекстових екранів опису використовуваних методів з інструментальних засобів; забезпечити підтримку процесу управління розробкою, зокрема, за рахунок взаємодії із засобом планування робіт MS Project, оцінювання трудомісткості проекту, відстеження виконання робіт, створення графіків робіт, та інОсобливо важливими є можливість авторизації методології та інтерактивний доступ будь-якого розробника до опису будь-якого методу або процесу в потрібний йому момент часу. На сучасному етапі розвитку технології, в умовах швидкої зміни як програмних і апаратних засобів, так і завдань бізнесу, методологія створення, супроводу і розвитку ПЗ не повинна бути незмінною, вона повинна мати можливість змінюватися і налаштовуватися на нові технології, методи та інструментальні засоби. Сучасні розробники великих ІС набувають одну або кілька методологій постачальника, а потім створюють на їх основі власні методології і технології, адаптовані до конкретних умов (див. підрозділ 1.3).
У SE Companion вихідним документом, що описує методологію (як процеси ЖЦ, так і всі супутні методи та методики), є файл у форматі MS Word. Це забезпечує можливості для опису методології з будь-яким ступенем деталізації, проведення розмітки для створення гіпертексту та авторизації методології в прийнятому стандартному форматі.
Гипертекстовое описание методологии и технологии создания ПО строится из описания процессов жизненного цикла, методов и методик, и представляет собой единый гипертекстовый документ в формате MS Help. Итоговое гипертекстовое описание получается в результате трансляции исходного документа. Все изменения и дополнения методологии производятся посредством корректировки и, возможно, дополнительной разметки исходного документа.
Описание методологии создания системы обычно состоит из раздела описания процессов ЖЦ и разделов описания методов и методик. В свою очередь, раздел описаний процессов состоит из иерархии описаний стадий, этапов и операций жизненного цикла с обязательным описанием выходных компонентов каждого процесса. Компоненты ПО создаются с применением методик и методов, описываемых в соответствующих разделах.
Минимальная конфигурация аппаратно-программных средств, требуемых SE Companion Authoring Tool:
процессор: i486/33; оперативная память: 4 Mбайт для просмотра гипертекста, 12 Mбайт для авторизации; дисковая память: 20 Mбайт; операционные среды: Microsoft Windows 3.1, Microsoft Windows for Workgroups 3.11, Microsoft Windows NT 3.5, Microsoft Windows 95. CASE-средства. Общая характеристика и классификацияСовременные CASE-средства охватывают обширную область поддержки многочисленных технологий проектирования ИС: от простых средств анализа и документирования до полномасштабных средств автоматизации, покрывающих весь жизненный цикл ПО.
Наиболее трудоемкими этапами разработки ИС являются этапы анализа и проектирования, в процессе которых CASE-средства обеспечивают качество принимаемых технических решений и подготовку проектной документации. При этом большую роль играют методы визуального представления информации. Это предполагает построение структурных или иных диаграмм в реальном масштабе времени, использование многообразной цветовой палитры, сквозную проверку синтаксических правил. Графические средства моделирования предметной области позволяют разработчикам в наглядном виде изучать существующую ИС, перестраивать ее в соответствии с поставленными целями и имеющимися ограничениями.
В разряд CASE-средств попадают как относительно дешевые системы для персональных компьютеров с весьма ограниченными возможностями, так и дорогостоящие системы для неоднородных вычислительных платформ и операционных сред. Так, современный рынок программных средств насчитывает около 300 различных CASE-средств, наиболее мощные из которых так или иначе используются практически всеми ведущими западными фирмами.
Обычно к CASE-средствам относят любое программное средство, автоматизирующее ту или иную совокупность процессов жизненного цикла ПО и обладающее следующими основными характерными особенностями:
мощные графические средства для описания и документирования ИС, обеспечивающие удобный интерфейс с разработчиком и развивающие его творческие возможности; интеграция отдельных компонент CASE-средств, обеспечивающая управляемость процессом разработки ИС; использование специальным образом организованного хранилища проектных метаданных (репозитория).Интегрированное CASE-средство (или комплекс средств, поддерживающих полный ЖЦ ПО) содержит следующие компоненты;
репозиторий, являющийся основой CASE-средства. Он должен обеспечивать хранение версий проекта и его отдельных компонентов, синхронизацию поступления информации от различных разработчиков при групповой разработке, контроль метаданных на полноту и непротиворечивость; графические средства анализа и проектирования, обеспечивающие создание и редактирование иерархически связанных диаграмм (DFD, ERD и др.), образующих модели ИС; средства разработки приложений, включая языки 4GL и генераторы кодов; средства конфигурационного управления; средства документирования; средства тестирования; средства управления проектом; средства реинжиниринга.Требования к функциям отдельных компонент в виде критериев оценки CASE-средств приведены в разделе 4.2.
Все современные CASE-средства могут быть классифицированы в основном по типам и категориям. Классификация по типам отражает функциональную ориентацию CASE-средств на те или иные процессы ЖЦ. Классификация по категориям определяет степень интегрированности по выполняемым функциям и включает отдельные локальные средства, решающие небольшие автономные задачи (tools), набор частично интегрированных средств, охватывающих большинство этапов жизненного цикла ИС (toolkit) и полностью интегрированные средства, поддерживающие весь ЖЦ ИС и связанные общим репозиторием. Помимо этого, CASE-средства можно классифицировать по следующим признакам:
применяемым методологиям и моделям систем и БД; степени интегрированности с СУБД; доступным платформам.Классификация по типам в основном совпадает с компонентным составом CASE-средств и включает следующие основные типы:
средства анализа (Upper CASE), предназначенные для построения и анализа моделей предметной области (Design/IDEF (Meta Software), BPwin (Logic Works)); средства анализа и проектирования (Middle CASE), поддерживающие наиболее распространенные методологии проектирования и использующиеся для создания проектных спецификаций (Vantage Team Builder (Cayenne), Designer/2000 (ORACLE), Silverrun (CSA), PRO-IV (McDonnell Douglas), CASE.Аналитик (МакроПроджект)). Выходом таких средств являются спецификации компонентов и интерфейсов системы, архитектуры системы, алгоритмов и структур данных; средства проектирования баз данных, обеспечивающие моделирование данных и генерацию схем баз данных (как правило, на языке SQL) для наиболее распространенных СУБД. К ним относятся ERwin (Logic Works), S-Designor (SDP) и DataBase Designer (ORACLE). Средства проектирования баз данных имеются также в составе CASE-средств Vantage Team Builder, Designer/2000, Silverrun и PRO-IV; средства разработки приложений. К ним относятся средства 4GL (Uniface (Compuware), JAM (JYACC), PowerBuilder (Sybase), Developer/2000 (ORACLE), New Era (Informix), SQL Windows (Gupta), Delphi (Borland) и др.) и генераторы кодов, входящие в состав Vantage Team Builder, PRO-IV и частично - в Silverrun; средства реинжиниринга, обеспечивающие анализ программных кодов и схем баз данных и формирование на их основе различных моделей и проектных спецификаций. Средства анализа схем БД и формирования ERD входят в состав Vantage Team Builder, PRO-IV, Silverrun, Designer/2000, ERwin и S-Designor. В области анализа программных кодов наибольшее распространение получают объектно-ориентированные CASE-средства, обеспечивающие реинжиниринг программ на языке С++ (Rational Rose (Rational Software), Object Team (Cayenne)).Вспомогательные типы включают:
средства планирования и управления проектом (SE Companion, Microsoft Project и др.); средства конфигурационного управления (PVCS (Intersolv)); средства тестирования (Quality Works (Segue Software)); средства документирования (SoDA (Rational Software)).На сегодняшний день Российский рынок программного обеспечения располагает следующими наиболее развитыми CASE-средствами:
Vantage Team Builder (Westmount I-CASE); Designer/2000; Silverrun; ERwin+BPwin; S-Designor; CASE.Аналитик.Описание перечисленных CASE-средств приведено в разделе 5. Кроме того, на рынке постоянно появляются как новые для отечественных пользователей системы (например, CASE /4/0, PRO-IV, System Architect, Visible Analyst Workbench, EasyCASE), так и новые версии и модификации перечисленных систем.
Література Вендров А.М. Один з підходів до вибору засобів проектування баз даних і додатків. "СУБД", 1995, № 3. Зіндер Є.З. Бізнес-реінжиніринг і технології системного проектування. Навчальний посібник. М., Центр Інформаційних Технологій, 1996 Калянов Г.М. CASE. Структурний системний аналіз (автоматизація та застосування). М., "Лорі", 1996. Марка Д.А., МакГоуен К. Методологія структурного аналізу і проектування. М., "Метатехнология", 1993. Міжнародні стандарти, що підтримують життєвий цикл програмних засобів. М., МП "Економіка", 1996 Створення інформаційної системи підприємства. "Computer Direct", 1996, N2 Шлеер С., Меллор С. Об'єктно-орієнтований аналіз: моделювання світу в станах. Київ, "Діалектика", 1993. Barker R. CASE * Method. Entity-Relationship Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. Barker R. CASE * Method. Function and Process Modelling. Copyright Oracle Corporation UK Limited, Addison-Wesley Publishing Co., 1990. Boehm BW A Spiral Model of Software Development and Enhancement. ACM SIGSOFT Software Engineering Notes, Aug. 1986 Chris Gane, Trish Sarson. Structured System Analysis. Prentice-Hall, 1979.