Специфікації станів

Стан об'єкта визначається значеннями його атрибутів і асоціацій. Наприклад, об'єкт Bankaccount (Банківський рахунок) може перебувати в стані "перевищення кредитного ліміту", якщо значення атрибута balance (баланс) негативне. Оскільки стани об'єкта визначаються структурам даних, моделі структур даних називаються специфікаціями станів.

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

У типовій ситуації спочатку визначаються класи-сутності, тобто класи, які визначають проблемну область і характеризуються постійною присутністю в базі даних системи. Подібні класи іноді називаються "бізнес-класами". Класи, які обслуговують системні події (керуючі класи) і класи, які представляють GUI-інтерфейс (класи представлення або прикордонні класи) не встановлюються доти, поки не стануть відомі поведінкові характеристики системи.

Моделювання класів

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

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

1. Знання в області моделювання класів.

2. Розуміння проблемної області.

3. Досвід в області аналогічних і успішних проектів.

4. Здатність дивитися вперед і передбачити наслідки рішень.

5. Готовність до перегляду моделі з метою усунення недоліків і т.д.

Останній момент пов'язаний з використанням CASE-засобів. Широкомасштабне застосування CASE-технології може стати перешкодою на шляху розробки системи в технологічно незрілих організаціях. Однак використання CASE-засобів для підвищення особистої продуктивності завжди виправдане.

Виявлення класів

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

Барамі (Bahrami) докладно вивчив головні особливості чотирьох основних підходів до виявлення класів (class discovery). Нижче перераховані ці підходи.

1. Підхід на основі використання іменних груп.

2. Підхід на основі використання загальних шаблонів для класів.

3. Підхід на основі використання прецедентів.

4. Підхід CRC (class-responsibility-collaborators - клас-обов'язку - "співробітники").

Барамі поставив у відповідність кожному з підходів опубліковані роботи, однак - на нашу думку - тільки останній підхід має незаперечне джерело.