"Гради Буч. Объектно-ориентированный анализ и проектирование с примерами приложений на С++ (fb2) " - читать интересную книгу автора (Буч Гради)

Объектно-ориентированный анализ и проектирование с примерами приложений на С++ Об автореПредисловиеЧАСТЬ ПЕРВАЯ КонцепцииГлава 1 Сложность1.1. Сложность, присущая программному обеспечению 1.2. Структура сложных систем 1.3. Внесение порядка в хаос 1.4. О проектировании сложных систем Выводы Дополнительная литература Глава 2 Объектная модель2.1. Эволюция объектной модели 2.2. Составные части объектного подхода 2.3. Применение объектной модели Выводы Дополнительная литература Глава 3 Классы и объекты3.1. Природа объекта 3.2. Отношения между объектами 3.3. Природа классов 3.4. Отношения между классами 3.5. Взаимосвязь классов и объектов. 3.6. Качество классов и объектов Выводы Дополнительная литература Глава 4 Классификация4.1. Важность правильной классификации 4.2. Идентификация классов и объектов 4.3. Ключевые абстракции и механизмы Выводы Дополнительная литература

ЧАСТЬ ВТОРАЯ Метод

Глава 5 Обозначения5.1. Элементы обозначений 5.2. Диаграммы классов 5.3. Диаграммы состояний и переходов 5.4. Диаграммы объектов   5.5. Диаграммы взаимодействия 5.6. Диаграммы модулей 5.7. Диаграммы процессов. 5.8. Применение системы обозначений Выводы Дополнительная литература Глава 6 Процесс6.1. Основные принципы 6.2. Микропроцесс проектирования 6.3. Макропроцесс проектирования Выводы Дополнительная литература Глава 7 Практические вопросы7.1. Управление и планирование 7.2. Кадры 7.3. Управление релизами 7.4. Повторное использование 7.5. Качество и измерения 7.6. Документация 7.7. Инструменты 7.8. Специальные вопросы 7.9. Выгоды и опасности объектно-ориентированной разработки Выводы Дополнительная литература ЧАСТЬ ТРЕТЬЯ Примеры приложенийГлава 8 Система сбора данных: метеорологическая станция  8.1. Анализ 8.2. Проектирование 8.3. Эволюция 8.4. Сопровождение Дополнительная литература Глава 9 Среда разработки: библиотека базовых классов9.1. Анализ 9.2. Проектирование 9.3. Эволюция 9.4. Сопровождение Дополнительная литература Глава 10 Архитектура клиент-сервер: складской учет10.1. Анализ 10.2. Проектирование 10.3. Эволюция 10.4. Сопровождение Дополнительная литература Глава 11 Искусственный интеллект: криптоанализ11.1. Анализ 11.2. Проектирование 11.3. Эволюция 11.4. Сопровождение Дополнительная литература Глава 12 Управление: контроль за движением поездов12.1. Анализ 12.2. Проектирование 12.3. Эволюция 12.4. Сопровождение Дополнительная литература ПослесловиеПриложение: Объектно-ориентированные языки программированияА.1. Концепции А.2. Smalltalk А.3. Object Pascal А.4. C++ А.5. Common Lisp Object System (CLOS) А.6. Ada A.7. Eiffel А.8. Другие объектно-ориентированные языки программирования Словарь терминовЛитературные ссылки

Глава 5 Обозначения

Составление диаграмм - это еще не анализ и не проектирование. Диаграммы позволяют описать поведение системы (для анализа) или показать детали архитектуры (для проектирования). Если вы понаблюдаете за работой инженера (программиста, технолога, химика, архитектора), вы быстро убедитесь, что будущая система формируется в сознании разработчика и только в нем. Когда, спустя некоторое время, система будет понятна в общих чертах, она скорее всего будет представлена на таких высокотехнологичных носителях, как тетрадные листы, салфетки или старые конверты [1].

Однако, хорошо продуманная и выразительная система обозначений очень важна для разработки. Во-первых, общепринятая система позволяет разработчику описать сценарий или сформулировать архитектуру и доходчиво изложить свои решения коллегам. Символ транзистора понятен всем электронщикам мира. Аналогично, над проектом жилого дома, разработанным архитекторами в Нью-Йорке, строителям из Сан-Франциско скорее всего не придется долго ломать голову, решая, как надо расположить двери, окна или электрическую проводку. Во-вторых, как подметил Уайтхед в своей основополагающей работе по математике, "Освобождая мозг от лишней работы, хорошая система обозначений позволяет ему сосредоточиться на задачах более высокого порядка" [2]. В-третьих, четкая система обозначений позволяет автоматизировать большую часть утомительной проверки на полноту и правильность. Как говорится в отчете управления оборонных исследований:

"Разработка программного обеспечения всегда будет кропотливой работой... Хотя наши машины могут выполнять рутинную работу и помогать нам держать нить рассуждений, разработка концепций останется прерогативой человека... Что всегда будет в цене - это искусство построения концептуальной структуры, а заботы об ее описании уйдут в прошлое" [3].