Терри Кватрани - Rational Rose 2000 и UML Визуальное моделирование

В главе 12 «Выпуск версий» рассматривается организация процесса выпуска версий. Здесь также приводится нотация языка UML для описания решений, принимаемых на этапе проектирования при создании версии. В этой главе не обсуждаются удачные или неудачные решения в области проектирования, а говорится о процессе и нотации, используемых для построения версий.

Приложение А «Генерация кода и возвратное проектирование для С++» описывает поэтапную последовательность действий для генерации кода и возвратного проектирования с использованием программы Rational Rose 2000 и языка С++.

Приложение В «Генерация кода и возвратное проектирование для Visual С++ и Visual Basic» содержит информацию о поэтапной последовательности действий для генерации кода и возвратного проектирования с использованием пакета Rational Rose 2000 и языков Visual С++ и 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. Треугольник успеха

Нотация является важной составляющей любой модели — она служит связующим звеном между процессами. «Нотация выполняет три функции:

□ является языком для описания взаимодействий, которые неочевидны или не могут быть получены непосредственно из кода;

□ обеспечивает достаточную семантику, позволяющую охватить важные стратегические и тактические решения;

□ предлагает конкретную форму, помогающую человеку рассуждать о предметной области, а средствам моделирования воплощать описанные идеи»[1].

Унифицированный язык моделирования (Unified Modeling Language — UML) предлагает достаточно полную нотацию, которая расширяется при переходе от анализа к проектированию. Определенные элементы нотации (например, классы, связи, агрегаты, наследование) используются на этапе анализа. Другие элементы (индикаторы реализации и свойства) вводятся на стадии проектирования.

В 90-е годы появилось большое количество различных методологий с собственными наборами нотаций. Самые популярные — ОМТ (по Рамбо), Booch (по Бучу) и OOSE (по Джекобсону). Каждая из них имела свои преимущества. Методика ОМТ отличалась хорошими средствами анализа и слабыми сторонами в проектировании, а методика Booch 1991, наоборот, более подходила для проектирования, чем для анализа. В методике OOSE основное внимание уделено развитым средствам поведенческого анализа, а в других областях отмечено много недостатков.

Спустя некоторое время Буч опубликовал второе издание, в котором собрал лучшие идеи и решения в области анализа, предлагавшиеся в том числе Рамбо и Джекобсоном. В свою очередь, Рамбо написал серию статей, известных как методика ОМТ-2, куда вошли предложения Буча в области проектирования. Перечисленные методики были достаточно похожи, но отличались разными нотациями — один и тот же символ имел в них различные значения. Например, закрашенный круг был индикатором множественности в методике ОМТ и символом агрегата в нотации Буча. Вы, наверное, слышали фразу «война методов», употреблявшуюся в период, когда класс обозначался либо в виде облака, либо в виде прямоугольника? Трудно понять, что же лучше.

Конец войне методов положила нотация, принятая в языке UML. «Язык UML служит для определения, отображения и описания элементов объектно-ориентированных систем в процессе их создания. Он объединяет объектную модель, нотации Буча и ОМТ, а также лучшие идеи, предложенные авторами других методик (рис. 1.2). Таким образом, язык UML является стандартом де-факто в области объектно-ориентированного анализа и проектирования»[2].