24.04.2012 Лекція

1. Поняття та процеси доменної інженерії та доменного аналізу програмного забезпечення.

2. Лінійки та сімейства продуктів.

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

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

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

Доменна інженерія включає в себе три основні компоненти-процеси – Доменний Аналіз (ДА), Доменне Проектування (ДП), Реалізація Домену (РД).

Основна мета кожного із цих компонентів:

Доменний Аналіз – визначення набору повторно використовуваних вимог для систем в домені.

Доменне Проектування – створення спільної (загальної) архітектури для систем в домені.

Реалізація Домену – реалізація повторно використовуваних ресурсів, наприклад, повторно-використовувані компоненти, доменно-орієнтовані мови, генератори і повторно використовувана інфраструктура.

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

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

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

Доменна інженерія розглядає наступні два аспекти:

• Інженерію повторно використовуваного ПЗ. Доменна Інженерія використовується для розробки повторно використовуваного ПЗ

• Управління знаннями. Доменна інженерія не повинна бути «одноразовою» діяльністю. Замість цього, вона повинна бути безперервним процесом, головною метою якого є підтримка і оновлення знань в домені на основі досвіду, розширення меж, і нові тенденції та ідеї.

ДОМЕННИЙ АНАЛІЗ

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

Метою ДА є:

• Вибір і визначення домену.

• Збір важливої (необхідної) інформації про домен і інтеграція її в зв’язану (єдину) модель домену.

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

ДА не тільки включає записи існуючих знань домену. Систематична організація існуючих знань дозволяє і заохочує розширювати їх в творчих цілях. Таким чином ДА є креативною діяльністю.

Доменна модель є явним представленням спільних і відмінних властивостей систем в домені і залежностей між відмінними властивостями. В загалі модель домену складається із наступних компонентів:

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

• Лексикон домену: Доменний лексикон визначає доменний словник.

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

• Моделі характеристик (можливостей). Визначають набір повторно використовуваних і конфігуруємих вимог до специфікованих систем домену. ДА зазвичай включає наступні процеси (діяльності):

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

2. Моделювання домену: розробка доменної моделі

Процеси ДА

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

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

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

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

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

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

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

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

   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 є перевірка доменної моделі і збір обґрунтувань домену.

Метод IDeA

Метод IDeA (Intelligent Design Aid) розроблений Lubars в 1991 році. IDeA представляє собою середовище проектування, що допомагає при проектуванні ПЗ і підтримує повторне використання абстрактних конструкцій, представлених у вигляді напівформальних схем проекту. Lubars використовує доменний аналіз для заповнення повторно використовуваних бібліотек.

Метод FODA

Метод FODA (Feature-oriented domain analysis) розроблений Інститутом програмної інженерії для знаходження спільних рис (можливостей/властивостей) у відповідних програмних системах, що можуть бути представлені в зручному форматі з картами в особливих випадках цих можливостей. Базуючись на надійних технологіях моделювання взятих із області програмної інженерії подібно ієрархічній декомпозиції і моделям сутність-зв'язок, метод FODA ближче до існуючих об’єднань інших методів. Переваги – по-перше, документація складається з детальних прикладів методів FODA; по друге, містить унікальну особливість: наявність декількох кроків перевірки; по третє, метод чітко визначає цілі, входи, виходи і внутрішні кроки кожної діяльності в процесі; і на кінець, метод FODA розкладає поняття «можливість» на функціональні, експлуатаційні. Можливості/властивості об’єднуються в ієрархії використовуючи відношення «consist is».

Метод Synthesis

Проект Synthesis в Software Productivity Consortium (SPC) призначений забезпечити членів своєї компанії методологією, яка інтегрується в підмандатний стандарт 2167А Міністерства оборони США. Методологія використовує доменний аналіз протягом фаз визначення системних і програмних вимог, побудови набору повторно використовуваних компонент, звертаючись до великого сімейства подібних систем. Подібно до метода FODA, він має відмінну документацію і опирається на результати декількох аналізів. Synthesis використовує репозитарій для зберігання всіх знань домену, які в свою чергу являються основою для процесу моделювання домену. SPC використовує об’єктно-орієнтований аналіз для формалізації вимог домену.

Доменне Проектування

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

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

Реалізація Домену – створення процесів і інструментів для ефективної генерації замовленої програми в домені.

Лінійки та сімейства продуктів.

Лінійка програних продуктів (Product Line Practice) – це вид виробництва продуктів по технологічній лінії із готових ресурсів (повторно використовуваних компонент, програми, застосувань, БД і т.д.) з метою задоволення потреб ринку

Технологія лінійки включає:

• обмеження, властиві продуктів лінійки;

• зразки і каркаси, що використані на лінії;

• виробничі обмеження, стратегії і методи;

• набір засобів і інструментів розробки продукту на лінії

• контроль плану робіт і вияв ризиків;

• прогнозування вартісних і технічних ресурсів проекту;

• технологія управління конфігурацією;

• вимірювання та оцінка показників якості продукту.

Сімейство систем (systems family) – сукупність ПС сімейства із спільним і управляємим набором характеристик домену. Спосіб виготовлення – Доменна Інженерія або контейнерне виробництво (типу Product line) з єдиною схемою базового процесу або каркасу для членів сімейства та інших програмних ресурсів.

Доменна інженерія – це вироблення сімейства систем на основі опису специфіки предметної області (домену) в DSL (Domain Specific Language), моделі характеристик членів сімейства і накопичення їх в репозитарії.