Саsе - технології проектування ІС

Для подолання труднощів і проблем у рамках но­вих інформаційних технологій створена і знаходить все більше поши­рення СASЕ-технологія проектування, яка базується на використанні СASЕ-продуктів − програмного, методичного та інформаційного забезпечення САПР ІС. В основу СASЕ-технології проектування покладено СASЕ-Method проектування систем. Розглянемо основні положення цієї методології.

СASЕ-СИСТЕМИ являють собою програмно-технічні комплекси, що базуються, як правило, на потужних ПЕОМ або робочих станціях ло­кальних мереж ЕОМ і реалізують у тому чи іншому обсязі концепції САПР ІС. У загальному випадку СASЕ-системи реалізують такі ви­ди підтримки проектних процедур:

- підтримку бази метаданих проекту;

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

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

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

- автоматизовану генерацію програмних продуктів за заданими спе­цифікаціями;

- інформаційну підтримку розробників ІС на основі словників да­них та ІПС;

- підготовку проектної документації.

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

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

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

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

Автоматизація генерування програмних продуктів базується на виконанні рутинних операцій кодування програм (опис даних, основна логіка обробки, схеми баз даних, описи інтерфейсів) за заданими специфікаціями з використанням спеціальних генераторів програм. Згідно з таким принципом генеруються, наприклад, тексти вихідної мови у системі СLАRІОN. У ряді.випадків автоматична генерація кодів про­грам може давати 90% їх обсягу.

Інформаційне забезпечення в САSЕ-системах має два аспекти:

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

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

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

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

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

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

На етапі 1 “Вироблення стратегії” визначаються:

- цілі створення системи та пріоритети й обмеження;

- будується модель системи;

- розробляється системна архітектура;

- затверджується план розробки системи.

На етапі 2 “Аналіз” виконуються такі роботи:

- будується модель інформаційних потреб (модель «сутність − звʼязок»);

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

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

- визначається загальний план впровадження системи;

- установлюються критерії прийому системи в експлуатацію.

Перші три роботи із зазначеного переліку фактично реалізують побудову «інформаційної моделі підприємства».

На етапі 3 “Проектування” виконуються такі роботи:

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

- будується концептуальна схема бази даних;

- здійснюється реляційне проектування бази даних;

- спеціалізуються функції, спроектовані на етапі аналізу;

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

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

- докладно планується етап реалізації системи.

На етапі 4 “Реалізація” виконуються такі роботи:

- створюється реляційна база даних;

- програмні реалізації задач установлюються на відповідних ЕОМ мережах;

- проводиться тестування і перевірка відповідності програмних продуктів вимогам користувача.

На етапі 5 “Документування” виконуються такі роботи:

- створюється системна документація;

- розробляються матеріали для навчання;

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

На етапі 6 “Впровадження” виконуються такі роботи:

- конвертування даних зі старих систем (у разі необхідності);

- проводиться подальше тестування програм;

- аналізуються функціональні можливості системи, її виробників;

- оцінюється якість засобів захисту даних від зруйнування не­санкціонованого доступу.

На етапі 7 “Експлуатація” виконуються такі роботи:

- підтримки системи;

- модифікації розробленої системи;

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

- моніторингу системи.

Сьогодні не існує реалізацій СASЕ-системи, які б дозволяли в од­ному продукті зосередити розвʼязання всіх задач проектування. У той самий час така тенденція має місце для багатьох фірм, що розробляють САSЕ-продукти. Так, у Великобританії використовується школа з чо­тирьох ступенів для оцінки відповідності СASЕ-продукту вимогам тех­нології SSАDМ. Оцінка проводиться на основі переліку сформульова­них критеріїв. Одержувані оцінки сконцентровані в основі процедури сер­тифікації СASЕ-продуктів, які створюються фірмами-виробниками програмних продуктів.

Проаналізуємо коротко основні задачі розробки, що розв'язуються з допомогою СASЕ-систем.

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

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

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

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

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

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

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

Група задач забезпечення розробників. Задачі налагодження сере­довища забезпечують можливість системному аналітику-проектуваль­нику налагоджувати конфігураційні й ергономічні параметри СASЕ-системи, характеристики метамоделей. Задачі експорту (імпорту) за­безпечують передачу розроблюваних фрагментів проекту (базу даних проекту) в іншу систему. Задачі адміністрування бази даних проекту забезпечують цілісність бази даних проекту, використання даних в інших проектах.

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

Система автоматизованого проектування на основі СASЕ-Method реалізується як інтегрована система, що складається з СASЕ-продуктів. Окремі СASЕ-продукти являють собою програми, що реалізують сукупності функцій САПР. Подальший розгляд проводитимемо на прикладі конкретної системи, розробленої фірмою ОRАСL.

До складу САПР фірми ОRАСL входять три базових СASЕ-про­дукти:

- СASЕ*Dictionary;

- СASЕ*Desiqner;

- СASЕ*Generator.

Для функціонування СASЕ-продуктів необхідно мати у складі САПР СУБД ОRАСL, що включає модулі SQL*Forms i SQL*Plus.

Побудована на основі зазначених СASЕ-продуктів САПР працює на більшості існуючих платформ (Sum, UNIX, VAX/VNS, MS-DOS).

Модуль СASЕ*Dictionary дозволяє зберігати й узагальнювати інформацію, що зʼявляється у процесі проектування інформаційної системи. Це словесна система, в якій зберігаються описи інформаційних модулів, функціональних вимог і програмних рішень.

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

Інформаційна модель в СASЕ*Dictionary будується на основі мо­делі «сутність − звʼязок». Проектувальнику надається можливість відображувати типи зв'язків ("1:1","1:М","М:М"), обовʼязкові та необовязкові атрибути сутностей і звʼязків, унікальні ключі, ієрархічні зв'язки об'єктів.

Для проектування прикладних задач:

- формується ієрархія функцій;

- будується модель подій, що відбуваються в системі;

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

- визначається частота виконання функцій.

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

СASЕ*Dictionary має набір утиліт, що дозволяють нормалізувати логічну та фізичну структури бази даних.

СASЕ*Dictionary дозволяє генерувати понад 70 стандартних звітів про модельовану проблемну сферу. Такі звіти включають списки обʼєктів, описи перехресних посилань і взаємного впливу обʼєктів один на одного.

Модуль СASЕ*Desiqner забезпечує графічний інтерфейс при роботі різних моделей проблемної сфери. Ця програма дозволяє будувати моделі у графічному режимі. Інформація про моделі заноситься до СASЕ*Dictionary.

Модуль працює в середовищі різних графічних оболонок

(X Windows, DECWindows, Presintaton Manager та iн.). Проектувальник може відкрити необмежену кількість вікон і в кожному з них викону­вати окреме завдання.

СASЕ*Desiqner має легкий для засвоєння, дружелюбний до кори­стувача інтерфейс, що включає: систему випадаючих меню, вікна, які проявляються, піктограми, підказки гіпертекст.

Модуль СASЕ*Desiqner включає утиліти “діаграмери” для побудо­ви чотирьох схем, що використовуються у проекті:

- ЕК-діаграми;

- діаграми ієрархії типів;

- діаграми потоків даних;

- діаграми матриць перехресних посилань.

СASЕ*Generator дозволяє автоматично підтримувати багаторівневу цілісність посилань у базі даних.

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

Інша обмеженість цілісності стосується зміни підпорядкування за­пису.