Краткое содержание глав
Порядок и нумерация глав в настоящем издании не изменились, но содержание многих глав обновилось. Рисунки и сообщения программы приведены для версии Rational Rose 2000. Серьезные изменения коснулись глав 5 и 11. В главе 5 "Способы взаимодействия объектов" диаграммы последовательности действий и диаграммы взаимодействий сохранены в логическом представлении системы. Это сделано для соответствия Rational Unified Process. В главе 11 "Проектирование системной архитектуры" изменения внесены для того, чтобы показать значки компонентов вместе с нотацией для интерфейсных классов.
Я также добавила приложения, в которых рассматриваются способы использования программы Rational Rose с языками Visual Basic и Visual С++.
В главе 1 "Что такое визуальное моделирование" обсуждаются преимущества визуального моделирования, история языка UML и этапы разработки программы.
Глава 2 "Начало проекта" содержит описание системы регистрации учебных курсов, которая используется в качестве основного примера книги.
Глава 3 "Создание прецедентов" описывает методы исследования поведения системы на основе прецедентов.
Глава 4 "Поиск классов" знакомит с основными подходами и нотацией для выделения объектов и классов системы. Здесь также рассматриваются понятия стереотипов и пакетов в языке UML.
В главе 5 "Изучение взаимодействия объектов" рассматривается добавление в систему сценариев, описывающих, как прецеденты реализуются путем взаимодействия между наборами объектов. Здесь приводятся примеры использования диаграмм последовательности действий и диаграмм взаимодействий для получения сценариев.
Глава 6 "Определение отношений" иллюстрирует возможности установки отношений между классами системы. Отдельно обсуждаются понятия ассоциации и агрегации.
Глава 7 "Добавление поведения и структуры" содержит информацию о способах добавления структуры и поведения классов к модели системы.
Глава 8 "Изучение наследования" знакомит с принципами наследования и отношения типа подкласс-суперкласс.
В главе 9 "Анализ поведения объекта" рассказывается об использовании диаграмм переходов и состояний для анализа классов с выраженным динамическим поведением.
В главе 10 "Проверка модели" обсуждаются методы проверки целостности моделей, применяемые при параллельной работе над проектом нескольких рабочих групп.
Глава 11 "Проектирование системной архитектуры" знакомит с понятиями и нотацией для описания и документирования системной архитектуры. Данная глава не является полным руководством по разработке архитектуры, она лишь описывает нотацию и процессы, необходимые для ее определения, представления и документирования. Эти сведения специально размещены именно здесь, потому что архитектурные решения используются в последующих главах.
В главе 12 "Выпуск версий" рассматривается организация процесса выпуска версий. Здесь также приводится нотация языка UML для описания решений, принимаемых на этапе проектирования при создании версии. В этой главе не обсуждаются удачные или неудачные решения в области проектирования, а говорится о процессе и нотации, используемых для построения версий.
Приложение А "Генерация кода и возвратное проектирование для С++" описывает поэтапную последовательность действий для генерации кода и возвратного проектирования с использованием программы Rational Rose 2000 и языка С++.
Приложение В "Генерация кода и возвратное проектирование для Visual C++ и Visual Basic" содержит информацию о поэтапной последовательности действий для генерации кода и возвратного проектирования с использованием пакета Rational Rose 2000 и языков Visual C++ и Visual Basic.
Приложение С "Примеры программ на Visual Basic" посвящено способам создания и использования динамических библиотек Visual Basic.
В глоссарии перечислены основные термины, используемые в книге.
Благодарности
Я хотела бы поблагодарить многих людей за помощь в создании, оформлении и распространении моей книги.
Особую признательность я выражаю Стиву Бейли (Steve Bailey), Нэвине Берэни (Naveena Bereny), Керту Биттеру (Kurt Bitter), Грейди Бучу (Grady Booch), Джиму Коналлену (Jim Conallen), Эду Делио (Ed Delio), Лизе Дорнел (Lisa Dornell), Мэту Дразелу (Matt Drahzal), Марии Эриксон (Maria Ericsson), Джиму Форду (Jim Ford), Адаму Франклу (Adam Frankl), Скоту Фромэну (Scott Frohman), Джиму Джилеспи Qim Gillespie), Дороти Грин (Dorothy Green), Джону Хопкинсу (Jon Hopkins), Айвару Джекобсону (Ivar Jacobson), Джэйсону Джэймсу (Jason James), Филиппу Крачтену (Philippe Kruchten), Эрику Липановичу (Eric Lipanovich), Питеру Лаки (Peter Luckey), Грэгу Мэйерсу (Greg Meyers), Сью Майкл (Sue Mickle), Лоре Малине (Laura Mullins), Лэри Обрайену (Larry O'Brien), Сильвии Нэчеко (Sylvia Pacheco), Джиму Пьетрокарло (Jim Pietrocarlo), Хьюго Санчесу (Hugo Sanchez), Чарли Снайдеру (Charlie Snyder), Лин Стил (Lynne Steele), Уокеру Ройсу (Walker Royce), Джиму Рамбо (Jim Rumbaugh),ToMy Шульцу (Tom Schultz), Джону Смиту Qohn Smith) и Дейву Тропеано (Dave Tropeano). Спасибо также редактору моей книги Картеру Шанклину (Carter Shanklin) и его помощнику Кристин Эриксон (Kristin Erickson) - без их содействия эта книга не была бы напечатана.
Принятые обозначения
Для облегчения работы с текстом в книге приняты следующие соглашения:
фрагменты примеров, важные операторы, классы, объекты, прецеденты, атрибуты, пакеты обозначены специальным шрифтом (Courier);
важные объяснения, базовые определения и термины, встретившиеся впервые, выделены курсивом;
команды, клавиши и пункты меню даны полужирным шрифтом;
для обозначения последовательности выполнения команд меню используется символ =>, например: New => Actor.
Существует несколько общепринятых вариантов именования объектов, когда в их названия необходимо включить несколько слов. Поскольку многие языки программирования не поддерживают пробелы в именах объектов, то назвать объект несколькими словами не получится. Один из способов - слова внутри имени разделять символом подчеркивания (например, number_of_students). Другой - слова внутри имени писать слитно, но каждое слово начинать с заглавной буквы (например, numberOfStudents). В оригинале используется второй вариант, известный как "Венгерская нотация". Но поскольку русский перевод имен объектов модели все равно не преобразуется напрямую в имена объектов языка программирования, то в данной книге эти названия, выделенные моноширинным шрифтом, приводятся с пробелами, например: количество студентов.
Глава 1. Что такое визуальное моделирование
Визуальным моделированием (visual modeling) называется способ представления идей и проблем реального мира с помощью моделей. Модель помогает понять проблему всем участникам, задействованным в реализации проекта на различных этапах: заказчику, эксперту, аналитику, проектировщику, автору документации, программисту и др. Моделирование обеспечивает более точную оценку необходимых ресурсов, четкую проработку планов и эффективное функционирование создаваемых систем.
Модель (model) - это абстракция, описывающая суть сложной проблемы или структуры без акцента на несущественных деталях, тем самым делая ее более понятной. Абстрагирование - одна из основных способностей человека, которая позволяет разбираться в сложных вещах. Инженеры, артисты, ремесленники используют модели на протяжении тысячи лет, чтобы сначала проверить изделие или замысел, а потом приступить к его реализации. Разработка программного обеспечения - не исключение. Для построения сложной системы необходимо сначала разделить ее на несколько абстрактных представлений и построить модели, используя принятые обозначения - нотацию (notation). Затем убедиться, что модели удовлетворяют всем потребностям системы, и постепенно добавлять детали для перехода от моделей к реализации.
Мы строим модель сложной системы, потому что не можем охватить и понять проект целиком. Существуют пределы в понимании сложных вещей. Это можно продемонстрировать на примере архитектуры. Если вы хотите построить сарай во дворе, вам достаточно просто начать строительство. Когда вы планируете построить новый дом, вам наверняка потребуется чертеж. А для возведения небоскреба он будет просто необходим. Этот же пример можно привести для программного обеспечения. Изучая работу отдельной формы в Visual Basic, программист не сумеет представить схему проекта целиком. Создание модели позволяет представить общую картину взаимодействия узлов системы без углубления в детали реализации отдельных элементов.
Модели помогают нам организовывать, отображать, понимать и создавать сложные вещи. Они призваны помочь в решении трудных задач при разработке программ сегодня и в будущем.
Треугольник успеха
Я часто использую треугольник успеха (triangle for success), показанный на рис. 1.1, чтобы изобразить средства, необходимые для успешного проекта. Вам потребуются все три грани - три составляющие - нотация, процесс и инструмент. Можно изучить нотацию, но если вы не знаете, как ее применить (организовать процесс), то, вероятно, потерпите неудачу. У вас могут быть хорошо организованные процессы, но если вы не сумеете описать порядок их взаимодействия (используя нотацию), то, скорее всего, вам не удастся довести проект до конца. И наконец, если вы неправильно определите орудия труда (инструменты), вас наверняка постигнет неудача.
Рис. 1.1. Треугольник успеха