Rational Rose 2000 и UML. Визуальное моделирование - [3]
Для облегчения работы с текстом в книге приняты следующие соглашения:
□ фрагменты примеров, важные операторы, классы, объекты, прецеденты, атрибуты, пакеты обозначены специальным шрифтом (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 основное внимание уделено развитым средствам поведенческого анализа, а в других областях отмечено много недостатков.