Технологія проектування SSАОМ

У ряді зарубіжних країн використовують­ся інші підходи до проектування IС, що мають як переваги, так і недоліки. Однією з найбільш досконалих серед таких технологій є промислова інформаційна тех­нологія SSАDМ (Structured Systems Analysis and Design Method) (Метод аналізу і проектування структурних систем), розроблена У Великобританії в середині 70-х років, а в 1993 році стала стандартом для використання у всіх проектах інформаційних систем, які фінансувалися з бюджету. Також вона отримала широке використання у Західній Європі і Японії. У 1994 році розроблена 4 версія де використовувалися інструментальні засоби проектування інформаційних систем.

Особливістю SSАDМ є великий обсяг проектних робіт при неавтоматизованому проектуванні, але для автоматизованого проектування ця технологія є найкращою на сьогодні.

Створюючі технології SSАDМ, розробники керувались рядом основних принципів:

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

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

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

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

- формалізація процесу розробки, що забезпечує широке використання засобів автоматизації проектування.

У технології SSАDМ можна умовно виділити дві основні складові частини: типовий технологічний процес і методичне забезпечення.

Типовий технологічний процес (ТТП) складається з п'яти укрупнених стадій: оцінка реальності виконання, аналіз вимог, розробка технічного завдання, логічне проектування і фізичне проектування. Вони включають сім детальних технологічних стадій, що складаються з етапів, які, у свою чергу, поділяються на операції. Деякі документи, наприклад “Каталог вимог” і «Логічна модель даних», є вхідними для кількох стадій. Це відображує ітераційний характер процесу вироблення проектних рішень, передбачений технологією SSАDМ.

Стадія 0. «Оцінювання реалізованості» не є обов'язковою і може бути опущена, якщо раніше були проведені достатньо глибокі дослідження під час вироблення стратегії автоматизації. Основною метою стадії є попереднє техніко-економічне обгрунту­вання проекту і розроблення концепції майбутньої ІС.

Стадія 1. «Передпроектне обстеження». Мета – побудувати формалізовану модель існуючої системи, визначити ос­новні вимоги до нової ІС, вивчити існуючу систему обробки інформа­ції, скласти з участю користувачів Логічну схему даних, опис у термінах по­токів даних, задач та інформаційних об'єктів. Визначають межі існуючої системи, зовнішні об'єкти та функції користувачів. При цьо­му, аналізуючи її недоліки, формулюють основні вимоги до нової ІС, що відображують у каталозі вимог.

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

Стадії 3. «Розробка технічного завдання». Метою є складення повного формалізованого опису вимог до нової системи у відповідності з варіантом вибраним на попередній стадії. Вимоги фор­мулюють у термінах потоків даних, задач та інформаційних об'єктів. Крім того, у термінах подій і даних розробляють вимоги до динаміки функціо­нування ІС. Характерно, що на цій стадії передбачена також розробка демонстраційного прототипу, який призначений для оцінки наскільки відповідають вимогам користувачів форми вхідних і вихідних повідомлень та структура діалогової взаємодії.

Стадія 4. «Вибір варіантів технічної реалізації» Роботи аналогічні стадії 2 і відрізняються від неї лише тим, що тут йдеться про обгрунтований вибір технічної та програмної реалізації створюваної ІС.

Стадії 5. «Розробка логічного проекту». Вона виконується пара­лельно стадії 4, і мета спроектувати комплекс програмних засобів на логічному рівні, що не залежить від середовища реалізації. Розроблюють логіку діалогової взаємодію користувачів із сис­темою, проектують алгоритми задач обробки даних а також інформаційну взаємодію задач.

Стадії 6. «Фізичне проектування». Мета – спроектувати фізичний опис даних у вибраному середовищі та розробити завдання на розробку програмних компонентів нової ІС. Описують дані на фізичному рівні, виконують їхню оптимізацію, уточнюють постановки задач і го­тують вказівки щодо генерації баз даних і розробки програмного за­безпечення стосовно до обраного середовища реалізації.

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

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

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

З метою полегшення залучення користувачів у процес розробки ряд методик базується на інтенсивному використанні подання проек­тних рішень у графічній формі, що забезпечує достатню наочність і не вимагає для розуміння їх сутності спеціальної підготовки у сфері інформаційних технологій. Така форма, наприклад, лежить в основі методик «Моделювання інформаційних потоків», «Логічне моделюван­ня даних», “Моделювання подій” та деяких інших.

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

Від відомих аналогій методичне забезпечення технології SSАDМ відрізняється важливою новизною, що дозволяє значно підвищити якість проектування. Йдеться про поняття «подія», яке поряд з понят­тями «дані» і «задачі», посідає в SSАDМ центральне місце. У спеціальній літературі проектування ІС, як правило, розглядається у термінах «дані» — «задачі». При цьому питання аналізу й опису ди­наміки функціонування ІС відкладають на пізні стадії розробки. Вве­дення на розгляд поняття «подія» дозволяє перенести прийняття про­ектних рішень з цих питань на різні стадії, і фіксувати їх у проектних документах у достатньо загальному вигляді, у формі, зрозумілій ко­ристувачам, які у такий спосіб одержують змогу контролювати пра­вильність рішень на змістовному рівні.

Крім того, якщо традиційні методи проектування орієнтовані на подання проекту майбутньої системи тільки у просторі «дані»— «за­дачі», то технологія SSАDМ дозволяє розглядати проект у ще двох про­екціях — «дані» — «подія» і «події» — «задачі». Наявність цих двох додаткових аспектів дозволяє розробникам ще на ранніх стадіях вияв­ляти приховані протиріччя у проекті та усувати помилки задовго до того, як вони могли б бути виявлені при традиційному підході.

Основними провідними документами із застосування технології SSАDМ є відповідний британський національний стандарт і довідкове керівництво.

Стандарт регламентує типовий технологічний процес створення ІС, склад вхідних і вихідних проектних документів на окремих стадіях і порядок взаємодії замовника і розробника ІС. За своїм призначен­ням, змістом і обсягом (близько 150 сторінок) він аналогічний діючому державному стандарту групи 34 «Інформаційна технологія». Відмін­ність британського стандарту полягає у тому, що межі SSАDМ охоп­люють, в основному, питання проектування інформаційного та про­грамного забезпечення ІС.

У технології SSАDМ досягнуто істотно великої чіткості в регламентації проектних процедур, особливо у частині, що стосується управління розробкою та контролю якості. З цією метою уся сукупність проектної документації технології SSАDМ поділена на три категорії:

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

Перевагою вітчизняних державних стандартів є реалізація раціональної структури ТТП, яка багато в чому аналогічна прийнятій у SSАDM, особливо у частині, що стосується ранніх стадій створення ІС, Проте вітчизняні державні стандарти майже не дають відповідей на питання «як?»; частенько ставлячи розробників у скрутне становище. Так, повністю незадовільно у державних стандартах групи 34 рішені питання передпроектного обстеження й особливо складання технічного завдання. На стадії «Робоча документація» з питань розробки програмного забезпечення ІС дано посилання на комплекс стандартів ЄСПД, який, як відомо, практично не охоплює питань, що стосуються інформаційного забезпечення. У той самий час у процесі створення ІС, починаючи з ранніх стадій, проектування програмного та інформаційного забезпечення тісно переплітаються.

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

Як визначають автори четвертої версії технології SSАDМ, без за­сування засобів автоматизації, проектування її можна реалізувати під час розроблення лише невеликих навчальних проектів.

14.4. САЗЕ — Технології проектуванняІС

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

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

- сутностями й атрибутами;

- бізнес-функціями;

- бізнес-компонентами;

- таблицями та стовпцями бази даних;

- прикладними програмними модулями.

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

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

Модуль працює в середовищі різних графічних оболонок (X Windows, DECWindows, Presintaton Manager та iн.). Проектувальник може відкрити необмежену кількість вікон і в кожному з них викону­вати окреме завдання,

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

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

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

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

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

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

Друкування побудованих діаграм може здійснюватися як на фоно-будівниках типу НР/GL, так і на принтерах, що підтримують роst-script.

Модуль СASЕ*Generator призначений для автоматичної генерації прикладних програм модулів. Прикладні задачі розробляються у виг­ляді послідовності операторів мови SQL.

Генеровані модулем форми звітів відображуються у специфіка­ціях проектів. Залежно від того, чи повна сумісність вихідних текстів ОRАСL. на всіх платформах, створені прикладні задачі можуть пере­носитися з платформи на платформу. Наприклад, можна спроектувати прикладну задачу на РС, а виконувати її на великій машині типу 1ВМ, НР або VАХ.

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

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

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

Приклад. Можна заборонити або дозволити переведення службов­ця з одного відділу в iнший.

СASЕ*Generator дозволяє будувати форми документів на основі однієї або кількох таблиць даних. Документ може розташовуватися на одному або кількох екранах.

14.5. Проектування ІС з використанням засобів мультимедіа

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

Які ж передумови інтеграції традиційних ІС із системами мультимедіа? Їх кілька:

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

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

Дослідження показують, що люди запам'ятовують лише 20% побаченого, 30% почутого, 50% побаченого і почутого одночасно й цілих 80% того, що вони одночасно бачили, чули і робили, а саме останнє і є сутністю мультимедіа.

Дві причини успіху техніки мультимедіа:

- одна застосовується у багатьох сферах бізнесу;

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

Багато аналітиків вважають, що до середини 90-х років засоби мультимедіа стануть невід'ємним компонентом настільних ПК.

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

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

4) підвищення рівня «інтелектуальності» ІС, з якою спілкується ОПР, веде до виникнення і посилення позитивного зворотного зв'язку системі ОПР - ІС за процесом «генерація альтернатив рішення проблеми»;

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

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

Поряд з терміном «мультимедіа» в літературі з інформаційних технологій зустрічається термін «гіпермедіа» (hypermedia — гіперсередовище). При цьому різні автори і фахівці можуть вкладати у ці поняття різний зміст. Про це треба пам'ятати під час роботи з літературними джерелами.

Як приклад системи мультимедіа розглянемо широко поширену систему Нурег Саrd, створену фірмою Аррlе для комп'ютерів Масіntosh.

Нурег Саrd — це оболонка, надбудова над операційною системою, що поєднує в собі властивості гіпертексту і об'єктно-орієнтованої мови. Система оперує такими об'єктами, як «карти», «стеки», «кнопки», «по­ля», «фон». Нурег Сагd подає користувачеві електронний еквівалент «карток». Це логічні об'єкти, які можуть містити інформацію різних типів — текст, графіку, відео. Вони з'являються на екрані у вигляді індексних карток розміром 3х5 дюймів, що мають «етикетки» (tag). Зв'язки між картками встановлюються з допомогою «кнопок» (button). Кнопки подаються на екрані у вигляді картинок, стрілок, слів або затінених областей. Натиснення кнопки викликає певну відповідну ре­акцію. Для описання поведінки об'єктів і зв'язків між ними викори­стовується мова Нурег Таlк.

Формування ринку мультимедіа на ІВМ - сумісних комп'ютерах поклало основу старт МРС (МиІtішеdіа РС). Цей стандарт розробле­ний фірмою Місгоsоft разом з іншими великими фірмами. Відповідно до цього стандарту мінімальна конфігурація МРС поряд з тра­диційними апаратними засобами має включати:

- нагромаджувач на СР-RОМ:

- АЦП, ЦАП, мікросхему музичного синтезатора, мікрофонний вхід, аналогове мікшування;

- Windows з Місгоsoft Мultimedia Ехtention.

Технологія мультимедіа висуває нові вимоги до користувальницького інтерфейса. Традиційні «двовимірні» desktor, екрани Ореnооk або Нехt на великих моніторах з великою кількістю вікон, що перекрива­ють одне одного, набувають гірші властивості прототипу (робочого сто­лу). Екран стає схожим на завалений паперами стіл, де необхідний папір важко знайти і витягти з купи інших. Але за тим, що відбу­вається «на столі», важко слідкувати, всі частини екрана важко утри­мувати у полі зору.

Розроблена фірмою Sun нова операційна система Solaris враховує вимоги і досягнення мультимедіа. Так, до її складу входить ЗР - Ореnооk - просторовий розвиток desktor-метафори. Фірма Аrk Іnterlace розробила пакет Workapace, який замість стола подає на ек­рані перспективу робочого кабінету з письмовим столом, шафами, по­лицями і шухлядами. У шухлядах можна зберігати (і вилучати у разі необхідності) дані і програми-інструменти.

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

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

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

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

2. Розроблення інструментальних засобів мультимедіа.

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

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