Застосування системи позначень

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

Глава 2

Процес

Основні принципи.

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

· Чітке уявлення про архітектуру створюваної системи;

· Добре організований Ітеративний розвивається процес роботи над проектом.

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

Глава 3

Практичні питання

Управління і планування.

Управління ризиком. Головний обов'язок менеджера програмного продукту - це управління як технічним, так і нетехнічними ризиком. Технічний ризик для об'єктно-орієнтованої системи міститься в вирішенні таких проблем, як вибір структури успадкування класів, забезпечує найкращий компроміс між зручністю і гнучкістю програмного продукту. Нетехнічний ризик містить у собі такі питання, як контроль своєчасності постачання програмних продуктів від третіх фірм або регулювання відносин замовника та розробників, що необхідно для з'ясування реальних вимог до системи на стадії аналізу. Багато видів діяльності з управління розробкою програмного забезпечення, наприклад, планування завдань і перегляди, передбачені не тільки в об'єктно-орієнтованої технології. Однак при управлінні об'єктно-орієнтованим проектом намічені завдання та розглядаються результати не зовсім такі, як в інших системах.

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

Кадри

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

Ролі розробників. Корисно пам'ятати, що розробка програмного продукту в кінцевому рахунку здійснюється людьми. Розробники - не взаємозамінні частини, і успішне створення будь-якої складної системи вимагає унікальних і різноманітних навичок усіх членів цілеспрямованого колективу. Архітектор проекту - її творець, людина з сильно розвиненим уявою; він відповідає за еволюцію і супровід архітектури системи. Дуже погана практика - наймати архітектора з боку, який, образно висловлюючись, в'їжджає на білому коні, проголошує архітектурні принципи, у той час як інші намагаються справитися з наслідками його рішень. Набагато краще залучити архітектора до активної роботи вже при проведенні аналізу і залишити його на як можна більш тривалий термін, навіть на весь час еволюції системи. Відповідальні за підсистеми - головні творці абстракцій проекту. Вони відповідають за проектування цілих категорій класів або підсистем. Прикладні програмісти (інженери) - молодші за рангом учасники проекту. На них покладено виконання двох обов'язків. Деякі з них відповідають за реалізацію категорії або підсистеми під керівництвом її ведучого. Ця діяльність може включати в себе проектування деяких класів, але в основному пов'язана з реалізацією і подальшим тестуванням класів і механізмів, розроблених проектувальниками команди. У великих проектах можуть знадобитися і інші ролі. Більшість з них явно не пов'язані з об'єктно-орієнтованої технологією, але деякі безпосередньо випливають з неї (такі, як інженер, що відповідає за повторне використання):

· Менеджер проекту - Відповідає за управління матеріалами проекту, завданнями, ресурсами та графіком робіт.

· Аналітик - Відповідає за розвиток та інтерпретацію вимог кінцевих користувачів.

· Інженер з повторного використання - Управляє сховищем матеріалів проекту.

· Контролер якості - Вимірює результати процесу розробки.

· Менеджер інтеграції - Відповідає за складання сумісних один з одним версій категорій і підсистем в релізи; стежить за їх конфігуруванням.

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