Інформаційні системи в менеджменті

 

 

 

 

 

34. Порівняльна  характеристика поколінь CASE- засобів

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

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

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

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

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

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

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

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

 

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

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

 

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

Єдина БД проекту. Основа CASE-технології - використання бази даних проекту (репозиторію) для збереження всієї інформації про проект, що може розділятися між розроблювачами відповідно до їхніх прав доступу .. Уміст репозиторію включає не тільки інформаційні об'єкти різних типів, але і відносини між їх компонентами, а також правила чи використання обробки цих компонентів..Репозиторій може зберігати понад 100 типів об'єктів: структурні діаграми, визначення екранів і меню, проекти звітів, опису даних, логіка обробки, моделі даних, їхні організації й обробки, вихідні коди, елементи даних і т.п..

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

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

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

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

Верифікація проекту. CASE-технологія забезпечує автоматичну верифікацію і контроль проекту на повноту і переконливість на ранніх етапах розробки, що впливає на успіх розробки в цілому - по статистичним даним аналізу п'яти великих проектів фірми TRW (США) помилки проектування і кодування складають відповідно 64% і 32% від спільного числа помилок, а помилки проектування в 100 разів сутужніше знайти на етапі супроводу ПО, чим на етапі аналізу вимог.

Автоматична генерація  об'єктного коду. Генерація програм у машинному коді здійснюється на основі репозиторію і дозволяє автоматично побудувати до 85-90% об'єктного чи коду текстів на мовах високого рівня.

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

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

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

таблиця 1

Традиційна технологія розробки	Розробка за допомогою CASE-технології
Основні зусилля - на кодування  і тестування	Основні зусилля - на аналіз і проектування
"Паперові" специфікації	Швидке ітеративне макетування
Ручне кодування	Автоматична генерація машинного коду
Тестування ПЗ	Автоматичний контроль проекту
Супровід програмного  коду	Супровід проекту

Концептуальні основи CASE-технології

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

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

· SADT (Structured Analysis and Design Technique) моделі і відповідні функціональні діаграми;

· DFD (Data Flow Diagrams) діаграми потоків даних;

· STD (State Transition Diagrams) діаграми переходів станів;

· ERD (Entity-Relationship Diagrams) діаграми "сутність-зв'язок".

У залежності від спрямованості CASE-продукту, він може підтримувати різного роду діаграми.

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

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

Засоби функціонального  моделювання

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

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

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

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

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

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

Нарешті, у частині автоматизованої  підтримки моделей приблизно 85-90% існуючих CASE-пакетів підтримують DFD і лише 2-3% - SADT.

Засоби подійного моделювання

Традиційний підхід до моделювання аспектів поведінки системи ґрунтується на розширенні діаграм потоків даних за рахунок введення керуючих потоків (сигналів) і керуючих процесів, що фактично є інтерфейсом між DFD і специфікаціями управління, власне моделююче поводження. Найбільше часто специфікації управління формалізуються за допомогою діаграм переходів станів (STD - state transition diagrams), що дозволяють задавати стану різних об'єктів системи (наприклад, особовий рахунок може мати стану ВІДКРИТИЙ, ЗАКРИТИЙ, ЗАБЛОКОВАНИЙ і т.п.), умови переходів з одного стану в інше (як зовнішні стосовно системи, так і внутрішні, виникаючі в самій системі), а також чинені при переходах дії.