Процеси ДА

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

На сьогодні існує безліч методів доменного аналізу. Це розмаїття може розглядатися як перевага (завжди можна запропонувати метод, який відповідає конкретним потребам «reuser»), або як недолік (виникає питання сортування за відповідними недоліками або спеціалізацією існуючих методів). Arango G., Wartic S., Prieto-Diaz R. оцінили різні методи ДА, зосередивши увагу на відмінностях в процесі ДA (як отримується доменна модель). Порівняльні дослідження, проведені Arango G. в 1994 на декількох методах ДА дали висновок, що всі методи ДА слідують загальному процесу, і що існує більше подібності між методами ніж відмінності.

Загальний процес доменного аналізу

1. Характеристика домену і планування – цей крок аналізує здійсненність ДА з комерційної та технічної точки зору. Якщо ДА можна здійснити, дані про домен визначаються і планується ДА. Крок складається з п’яти під кроків. Ці під кроки не є суворо послідовними; інформація від одного підкроку може вимагати перегляду більш ранніх під кроків.

1.1. Виділення домену – традиційний бізнес і методи аналізу ризику визначають здійсненність ДА. Організації використовують ці методи для вирішення чи є проект доцільним для компанії в даний час, чи правильно виділений домен, чи є обґрунтованим повернення інвестицій і чи домен достатньо зрілий для аналізу.

1.2. Опис домену – ця діяльність визначає область дії і зміст домену, і встановлює межі на роботу ДА.

1.3. Визначення відповідних даних – шляхом ідентифікації даних, доменний аналітик може вирішити чи достатньо відповідних даних існує, які є джерела даних і чи є достатній доступ до даних.

1.4. Створення переліку даних - складання опису (переліку) даних є необов’язковою діяльністю, яка готує безпосередньо до подальшого збору даних.

1.5. Планування проекту.

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

2.1. Відновлення абстракцій – доменний аналітик отримує (відшукує) докладну інформацію про існуючі додатки відносно відповідних компонент (наприклад, інтерфейс користувача, архітектури), поведінку та оригінальний дизайн системи і обґрунтування. Аналітик може використовувати реверсивну інженерію у відновленні абстракцій.

2.2. Огляд літератури

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

2.4. Розробка сценаріїв – сценарії пояснюють як зазвичай використовують системи користувачі та інші системи

3. Аналіз даних – в цій діяльності, доменний аналітик перевіряє дані на коректність, несуперечність і повноту.

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

3.2. Моделювання інформації – доменний аналітик моделює інформацію функціональною декомпозицією і декомпозицією даних чи об’єктно-орієнтованим аналізом, розробляє і записує проекти рішень.

3.3. Аналіз подібності – аналітик визначає схожість для того, щоб дозволити консолідацію подібних додатків.

3.4. Аналіз відмінності – аналіз пропонує перераховувати, параметризувати чи інкапсулювати відмінності.

3.5. Аналіз комбінацій – комбінації пропонують структурні чи поведінкові схеми і/або архітектури.

3.6. Аналіз компромісів – компроміси пропонують декомпозувати архітектури різними способами, що відповідають несумісним наборам вимог.

4. Класифікація – класифікація є основною моделюючою діяльністю в ДА. Вона збирає і детально формулює структуру інформації для класів додатків.

4.1. Описи груп – інформаційний пошук групуючих алгоритмів, інколи використовується для групування описів.

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

4.3. Класифікація описів – коли нові описи доступні, вони назначаються в групу або групи реорганізовуються, для включення нового опису.

4.4. Узагальнення описів – створюються ієрархії з метою зв’язування абстрактних описів разом.

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

5. Перевірка доменної моделі – критерії перевірки не включені в окремі методи і відповідно, не являються частиною загального процесу ДА, виділеного Arango.

Класифікація методів ДА

Хоча існує велика кількість методів ДА, але ніхто і ніколи не намагався їх класифікувати. Лише в 1992 році Arango і Wartik здійснили порівняння методів за різними критеріями.

Ferre X. і Vegas S.в своїй роботі запропонували класифікувати методи ДА в залежності від типу елементу, що буде повторно використовуватись:

1. Методи для повторного використання програмних компонентів (Draco, Mc Cain, Prieto-Diaz);

2. Методи для повторного використання активів (HP, ODM);

3. Методи для повторного використання архітектури / проектів ПЗ (FODA, IDeA, STARS, DADO);

4. Методи для повторного використання вимог до ПЗ (Synthesis, JODA).

Найбільш розповсюдженими підходами до ДА є підходи Synthesis, IDeA, KAPTUR, Prieto-Diaz, FODA.

Метод KAPTUR

KAPTUR (Knowledge Acquisition for Preservation of Tradeoffs and Underlying Rationales) є як інструментальним середовищем так і процесом доменного аналізу. Він розглядає повторне використання доменних активів з точки зору їх властивостей (можливостей), які представляють собою компоненти системи, об’єкти, функції в домені. Термін «можливість» використовується в іншому значенні чим методи FODA, Synthesis, де «можливості» відносяться тільки до функціональних характеристик системи. Підхід KAPTUR надає допомогу виробникам в 1) отриманні інформації із архітектурних видів і 2) у введенні і класифікації текстової інформації на всіх рівнях абстракції. Переваги метода KAPTUR є перевірка доменної моделі і збір обґрунтувань домену.

Читайте також:

<== попередня сторінка	\|	наступна сторінка ==>
Контроль статусу вимог	\|	Доменне Проектування

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

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