Деякі правила виявлення класів

Нижче наведений перелік керівних принципів або правил, яким повинен слідувати аналітик при виборі потенційних класів.

1.  Для кожного класу повинне бути ясно сформульоване його призначення в системі.

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

3.  Кожний клас (тобто клас-сутність) повинен містити набір атрибутів. Гарним прийомом є встановлення ідентифікуючих атрибутів (ключів), щоб допомогти нам судити про потужність (cardinality) класу (тобто очікуваній кількості об'єктів даного класу в базі даних). Слід, однак, пам'ятати про те, що клас не обов'язково повинен володіти користувальницьким ключем. Об'єкти класів ідентифікуються за допомогою ідентифікаторів об'єктів (OID) .

4.  Кожний клас повинен відрізнятися від атрибута. Чи представляється поняття класом або атрибутом який залежить від області додатка. Колір автомобіля зазвичай сприймається як атрибут класу Саг (Автомобіль). Однак на фабриці по виробництві фарб Color (Колір) - це визначений клас зі своїми власними атрибутами (яскравістю, насиченістю, прозорістю і т.д.).

Завдання: Виконати специфікацію вимог проекту. Виконати прототипування і розробку додатків проекту.

Надати звіт, що містить результати специфікації, прототипування і розробки додатків системи.

Контрольні питання:

1. Які принципи встановлення вимог?

2. Що таке домінантний клас?

3. Що таке відношення з'єднання?

4. Поясніть, у чому полягають основні відмінності чотирьох підходів до виявлення класів.

5. У чому полягає сутність підходу на основі використання загальних шаблонів класів?

Лабораторна робота № 3

Тема: Системне проектування. Проектування баз даних.

Ціль: Придбання практичних навичок системного проектування й проектування баз даних

Короткі теоретичні відомості

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

Архітектура програмного забезпечення

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

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

Опис системи в термінах її модулів називається архітектурним проектуванням (architectural design). Архітектурний проект включає вибір стратегії рішень у відношенні клієнтської і серверної компонентів системи.

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