Обгрунтуйте появу CASE-технологій.

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

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

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

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

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

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

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

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

 

 

24. Пояснити, що таке «варіант використання»? Як будується діаграма варіантів використання, і яку інформацію вона містить?

Варіант використання являє собою послідовність дій

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

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

Коли Якобсон в 1994 р. запропонував варіанти використання в якостіосновних елементів процесу розробки ПЗ, він також запропонував застосовувати дляїх наочного подання діаграми варіантів використання. На рис.1показані деякі варіанти використання для системи організації торгівлі;людські фігурки тут позначають дійових осіб, овали - варіантивикористання, а лінії і стрілки - різні зв'язку між діючимиособами і варіантами використання.

 

Рис.1 Діаграма варіантів використання

Дійова особа (actor) - це роль, яку користувач грає завідношенню до системи. На рис.1 чотири діючі особи: Менеджер зпродажу, Оптовий торговець, Продавець і Системи обліку. Дійові особиявляють собою ролі, а не конкретних людей або назви робіт.

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

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

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

На додаток до зв'язків між діючими особами і варіантамивикористання існують два інших типи зв'язків (див. рис.1):

"використання" (uses) і "розширення" (extends) між варіантамивикористання. Зв'язок типу "розширення" застосовується тоді, коли однаваріант використання подібний до іншого, але несе кілька велике навантаження

Вибір застосовуваної зв'язку визначається наступними правилами:

• зв'язок "розширення" слід застосовувати при описі змін донормальному поведінці системи;

• зв'язок "використання" слід застосовувати для уникнення повторів у двох

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

 

 

 

25. Пояснити каскадну модель ЖЦ ПЗ. Хто її розробив?

Каскадна модель життєвого циклу («модель водопаду», англ. waterfall model) була запропонована в 1970 р. Уїнстоном Ройсом.

Вона передбачає послідовне виконання всіх етапів проекту в строго фіксованій послідовності.

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

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

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

Ідеальне вживання моделі включає наступні вимоги:

ñ Строге дотримання послідовності етапів: новий етап не стартує, поки не закінчений попередній.

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

ñ Повернення до попередніх етапів при виявленні помилок реалізації або проектування в строгій зворотній послідовності

Переваги

ñ Можливість раннього виявлення помилок ще на етапах проектування.

ñ На кожному етапі підтримується цілісність проекту і проміжного продукту. В результаті текучість кадрів не складає проблеми, проект можна заморозити і відновити на будь-якому етапі.

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

ñ Можливе зручне планування і управління процесом, прогнозування термінів і витрат на реалізацію.

Недоліки

ñ Ідеальна схема недосяжна в реальному житті.

ñ Схема погано узгоджена з продовженням розробки і розширенням проекту.

ñ Розроблена в 70-і роки, коли процес виправлення коду був трудомістким, а можливості обчислювальних машин — обмеженими.

ñ Не дозволяє виділити абстракції, організувати доступ до спільних даних, розпаралеліти обчислювальні процеси, тощо

 

 

 

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

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

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

 

 

27. Пояснити ітераційну («спіральну») модель ЖЦ ПЗ. Хто її запропонував?

Спіральна модель (86—90-ті роки) — загострює увагу на

початкових етапах ЖЦ: аналізі вимог, проектуванні специфікацій, попередньому й детальному проектуванні. На цих етапах перевіряється і обґрунтовується реалізованість технічних рішень створенням прототипів.

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

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

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

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

Фахівці відзначають такі переваги спіральної моделі:

• накопичення і повторне використання програмних засобів, моделей і

прототипів;

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

• аналіз ризику і витрат у процесі проектування.