Модель аналізу вимог. Визначення об'єктів

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

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

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

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

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

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

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

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

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

об'єкти-сутності;
об'єкти інтерфейсу;
керуючі об'єкти.

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

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

Інтерфейси можна розподілити на два види: "з людиною" та "з системою". При виявленні інтерфейсних об'єктів визначальним є передбачення змін — кожну точку можливих змін у сценарії доцільно визначати як інтерфейсний об'єкт.

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

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

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

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

Модель аналізу має відповідну графічну нотацію:

Атрибути об'єктів представлені прямокутниками, поєднаними прямою лінією з символом об'єкта, при цьому на лінії вказується назва атрибута, а в прямокутнику — його тип.

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

Серед асоціацій застосовуються найпоширеніші:

"взаємодіє";
"складається з";
"виконує роль";
"успадковує";
"розширює";
"використовує".

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

Як приклади, на рис. 3.12 подано фрагменти моделі аналізу, що відповідають діаграмі сценаріїв бібліотечної системи, яку зображено на рис. 3.8.

<== попередня сторінка	\|	наступна сторінка ==>
Концепція моделі сценаріїв для збирання вимог	\|	Продукти інженерії вимог за методом І. Джекобсона

Не знайшли потрібну інформацію? Скористайтесь пошуком google:

Генерація сторінки за: 0.004 сек.