Проектування класів. Проектування баз даних
Проектування елементів системи виконується проектувальниками і включає:
· уточнення опису варіантів використання;
· проектування класів;
· проектування баз даних.
Уточнення опису варіантів використання полягає в модифікації їх діаграм взаємодії та діаграм класів з урахуванням новопосталих на етапі проектування класів і підсистем, а також проектних механізмів.
Проектування класів включає наступні дії:
· деталізація проектних класів;
· уточнення операцій і атрибутів;
· моделювання станів для класів;
· уточнення зв'язків між класами.
Кожен граничний клас перетвориться в певний набір класів, залежно від свого призначення. Це може бути набір елементів призначеного для користувача інтерфейсу, що залежить від можливостей середовища розробки, або набір класів, який реалізує системний або апаратний інтерфейс.
Класи-сутності з урахуванням міркувань продуктивності і захисту даних можуть розбиватися на ряд класів. Підставою для розбиття є наявність в класі атрибутів з різною частотою використання або видимістю. Такі атрибути, як правило, виділяються в окремі класи.
Що стосується керівників класів, то класи, що реалізують просту передачу інформації від граничних класів до сутностей, можуть бути видалені. Зберігаються класи, які виконують істотну роботу з управління потоками подій (управління транзакціями, розподілена обробка і т.д.).
Отримані в результаті уточнення класи підлягають безпосередньої реалізації в коді системи.
Обов'язки класів, певні в процесі аналізу і документовані у вигляді «операцій аналізу», перетворюються в операції, які будуть реалізовані в коді. При цьому:
· кожної операції присвоюється коротке ім'я, яке характеризує її результат;
· визначається повна сигнатура операції;
· створюється короткий опис операції, включаючи сенс всіх її параметрів;
· визначається видимість операції: public, private або protected;
· визначається область дії операції: операція об'єкта або операція класу.
Уточнення атрибутів класів полягає в наступному:
· задається його тип атрибута і значення за замовчуванням (необов'язково);
· задається видимість атрибутів: public, private або protected;
· при необхідності визначаються похідні (обчислювані) атрибути.
Якщо в системі присутні об'єкти зі складною поведінкою, то будують діаграми станів. Побудова діаграм станів може надати наступну дію на опис класів:
· події можуть відображатися в операції класу;
· особливості конкретних станів можуть вплинути на деталі виконання операцій;
· опис станів і переходів може допомогти при визначенні атрибутів класу.
В процесі проектування зв'язку між класами підлягають уточненню. Асоціацію між граничними і керуючими класами перетворюються в залежності. Агрегації, що володіють властивостями композиції, перетворюються в зв'язку композиції. Зв'язки узагальнення можуть перетворюватися в ситуаціях з так званої метаморфозою підтипів, коли об'єкт суперкласу може змінювати свій підтип.
Проектування баз даних проводиться, якщо використовується реляційна БД, при цьому класи-сутності об'єктної моделі відображаються в таблиці реляційної БД. Сукупність таблиць і зв'язків між ними може бути представлена у вигляді діаграми класів, яка, по суті, є діаграмою «сутність - зв'язок». Набір правил, що застосовуються при відображенні класів в таблиці БД, такий:
1. Кожна проста сутність, яка не є підтипом і не має підтипів, перетворюється в таблицю. Ім'я суті стає ім'ям таблиці.
2. Кожен атрибут стає можливим стовпцем з тим же ім'ям; може вибиратися більш точний формат.
3. Унікальний ідентифікатор сутності перетворюється в первинний ключ таблиці.
4. Якщо тип бінарної зв'язку між сутностями - один-до-одного і клас приналежності обох сутностей є обов'язковим, то з двох пов'язаних сутностей формується одна таблиця.
5. Якщо тип бінарної зв'язку - один-до-одного і клас приналежності однієї сутності є обов'язковим, а другий - необов'язковим, то формуються дві таблиці і ідентифікатор сутності, для якої клас приналежності є необов'язковим, додається в якості атрибута в таблицю, виділену для суті з обов'язковим класом приналежності.
6. Якщо тип бінарної зв'язку - один-до-одного і клас приналежності жодної суті не є обов'язковим, то формуються три таблиці: по одній для кожної сутності і одна для зв'язку.
7. Якщо тип бінарної зв'язку - один-ко-многим і клас приналежності сутності з потужністю "n" є обов'язковим, то формуються дві таблиці, при цьому ідентифікатор кожної сутності повинен служити первинним ключем відповідної таблиці. Крім того, ідентифікатор сутності з потужністю "1" додається як атрибут в таблицю, виділену для суті з потужністю "n".
8. Якщо тип бінарної зв'язку - один-ко-многим і клас приналежності сутності з потужністю "n" є необов'язковим, см. Правило 6.
9. Якщо тип бінарної зв'язку - багато-до-багатьох, см. Правило 6.
10. Для подання N-арной зв'язку потрібно N + 1 таблиця. Наприклад, в разі тернарного зв'язку формуються чотири таблиці, по одній для кожної сутності і одна для зв'язку. Таблиця зв'язку матиме серед своїх атрибутів ключі від кожної сутності.
11. Для зв'язку "супертип-підтип" можливі два способи перетворення:
a) всі підтипи в одній таблиці;
b) для кожного підтипу - окрема таблиця.
При застосуванні способу (а) для супертипу створюється таблиця, а для підтипів можуть створюватися уявлення (view). У таблицю додається принаймні один стовпець, що містить код типу.
З використанням методу (b) для кожного підтипу супертип відтворюється за допомогою операції об'єднання (UNION) - з усіх таблиць підтипів вибираються загальні стовпці - стовпці супертіпа.
Дата добавления: 2018-08-06; просмотров: 230; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!